你自己都说了 ClickHouse 需要跑 12s 才能完成的全表求和，你觉得大家的“轻轻松松”能是什么标准呢？反正面对一亿行全表统计，我个人视能在分钟内完成就是可以忍受的，到底是不是轻轻松松要看需求，如果数据再大一点，能完成而不因为各种内存空间不足报错就是可以忍受的。

@zzNucker 他这是全表扫描，索引并不能提供太多价值。

我觉得 #6 说的没太大毛病，就是说的太绕，不熟悉的人难以理解。Go 的 slice 设计本来就是个大坑，是缺乏思考或者说设计上懒惰的直接体现。append 操作返回值的模糊性导致相当场合 append 只有 x=append(x, blah) 这一个用法。

取决于实际情况，大部分情况下都倾向于设置，同时做好约束

单机搞定的话，PostgreSQL 。如果是大宽表低频率的分析，再考虑 ClickHouse 单机版这种事

装了监控软件不会让你干这种事的

几个原因，一个是累计误差，另一个是启动时的同步问题。
累计误差这个，现在很多芯片支持过采样，可以一定程度缓解。

Graal 也没有魔法啊，能优化优化速度完全是仗着把初始化好的 heap 存起来了。春天包含这老多东西，那内存不可能小啊

@finab 也不好说，毕竟天天用的 ls 命令它也启个进程，只要够轻，那就不叫事，而且平均下几秒钟一条推都了不得了似乎。蹲一个 iOS 聚聚（

@mxalbert1996 从 Sys UI 里强杀应该是收不到的，这个应该是 by design ，就是不清楚具体怎么实现的

@codehz 稍微搜了一下，苹果这似乎是把这个 "extension" 放进一个独立 bundle 里去了，不过我猜为了保证运行时的隔离应该还是独立的进程吧，这样是不是成本也不低？