之前有一个想法，把 B 表的 bitmap 聚合成一个 map，以 date 为 key，shop_id_bitmap 为 value，这样把表的维度压缩成 0 就能直接写在 where 条件里过滤 A 表的记录，但是翻了下文档好像并不支持这种用法，map 的 value 只支持几个简单的数据类型
最后还是决定加字段了
clickhouse 的单表 where 还是超级强力的

zgc 上生产以后还有调优的必要吗，java 8 的那几个收集器都滚蛋了
这个应该算是比较典型的死技术把
属于是纯纯的内卷了

@love
没垃圾回收很正常啊，C 就没垃圾回收
Rust 是
Memory safety without garbage collection;
Concurrency without Data Races;
Abstraction without Overhead

@AX5N 换个例子吧，webpack vs esbuild
这种性能差距可以填平多少年的硬件发展了

@silentt 好像的确没人关心 javac 是什么语言写的，都关注 jvm 了哈哈🐶

@winnie2012 需要满足同 app_id+date 时，A 表的 shop_id 包含在 B 表 shop_id_bitmap 里...

@kssdxw
A 是 replace merge tree
B 是 aggregating merge tree

我先用子查询把 A 限制到 10000 行，把 B 表 限制到 1 行，然后再 join B 表，
最外面的 select 只选 A 表的 app_id date 和一个字符串字段（长度 2 、30 左右）
结果都要 6.7 秒

join B 表的时候是结果有多少条就会把 B 表的 bitmap 复制多少次吗...这个 bitmap 的基数大概是几十万

@liprais
@aec4d
说实话我没搞懂这个 partition 和 order by 之间的关系
是数据按照 partition 分文件，然后文件内部用 order by 排序并按照粒度做了一个索引，如果查询的东西不再某个颗粒的索引范围就直接跳过这个颗粒包含的数据？
这个 A 表是用 app_id, toYYYYMM(date)...

@zzn
是的
差不多就是 select * ，因为主要内容就一个长度在 2 、30 左右的字符串，其他的都是相关信息，基本都是 uint8 、时间啥的，包括上面提到的一共就 9 列

作为真实开发后台管理系统的全栈（菜）
我们好像的确没有地方用到了跨组件通信
要用也是最基础的更新 redux 然后让另一个 connect redux 的组件变化这类吧

我现在都用文具剪刀剪
一周两次吧
原因就是你说的剃须刀刮完皮肤会红，很不爽

@Marxism C# 12 年就有了

ts 的类型系统很牛批
比 java 这种半调子强多了

@moxuanyuan 就是下载安装 gcc 所需文件的地址
去年还好好的，今年装了下，前几个文件下载正常，下到中间某个文件就报 404 了

@lovestudykid issue 已经有好几个了，有个 issue 里有解决方案，换了他给的源以后装是能装，但是编译的时候会报找不到 ld

官方文档说 next-key lock 是 record lock 和 gap lock 的组合