看 op 应该是 Oracle

猜测 union 查询命中了联合索引，所以不需要对 `datetime` 排序，只需要决定起始位置就可以直接 fetch 数据；而 IN list 先对命中三个条件的数据进行 merge ，然后 sort 后再筛选，无论是合并、排序操作还是需要扫描的行数（ 8989K > 2123K+180K ）都远比前一个查询计划大。

一种可行的优化可以尝试 over partition 拆成三个子表排序再重新 where 一下，不确定优化效果，需要再 explain 一下看看，参考 https://use-the-index-luke.com/sql/partial-results/window-functions

家里 Apex Pro TKL Wireless
公司 宁芝 Micro84

@lxdlam 补一句，通过 template + if constexpr + static_assert 可能可以将这个 `to_runtime` 自动化生成出来，不过我也好久没写过 C++ 了，如果不行当我没说。

本质的核心问题是 C++ 没有真正的 exhaustive 的 enum ，导致编译器无法限定 `E` 的值在一个可优化的 immedate value 范围内，无法将其在 comptime 求出来，所以将其放到参数里无法做编译期生成。

为什么 `to_runtime` 又能 work 了？因为在当前场景下，编译器推导出来对于 `consteval` 函数 `flattern`，可行的值是有限的，所以能够正常编译。把最后一个分支改为 `f(_e)`，编译器会报错 `f` 为一个 `consteval function`，但是参数是 comptime unknown 的。

对于有 exhaustive enum 的语言（ rust 、zig 等），要实现这种需求应该是 trivial 的。

DuckDB ，非常好用的 in memory OLAP 数据库，跟 sqlite 一样，而且可以统一连接 csv 、parquet 、mysql 、postgres 数据源，python 包可以兼容 pandas/polars/arrow ，纯粹开箱即用，非常方便

@lxdlam 没写完发出去了。补充一下特性第一条：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑可以读写分离的架构，使用一些缓存、分片的技术难度会大幅下降，且能在合理资源量内得到一个不错的效果。

日志需要持久化，尤其是有跨天 case 的可能性。使用 MySQL 或者其他 OLTP DB 是一种方案，但是不是最好的方案。

将日志当作事件流，思考日志的使用场景：
- 问题定位：最常见的 case ，通过请求、用户、设备等等维度抽取一个特定的事件流分析，哪一步出现了问题，这种 case 通常需要对一些特定的 field 当作 key ，抽取查询相关联的事件。
- 数据分析：通过对特定事件进行聚合，计算出来一些业务或者技术指标，诸如平均响应时间、订单完成延迟等。这种场景一定程度上会被 metric 所替代，但是在错误日志聚合上仍然有价值。

同时，日志有一些自己的特性：
- Append only：日志绝大部分情况下不会有并发读写，且是 Append only ，我们更多考虑
- 丢失冗余：根据日志量的关系，其实允许一定程度的日志丢失和冗余，也就是没有严格事务要求。
- 量级和查询需求：很多日志都是大海捞针，允许一定的查询延迟和一定延长的运行时间

从上面的角度，其实使用一个 OLAP 系统或者更加专门的系统更好。OLAP 常规的选型可以选择诸如 ELK 、ClickHouse 这样的系统，搭配 Kafka 之类将日志落进去；而比较完善的日志系统现在比较流行的就是 Loki + Promtail/Grafana Agent ；如果量小，使用 fluentd 采集并发送到 S3 使用一些脚本去分析也是 OK 的。

Redis 这次换其实是比较强盗逻辑的。

背景是 Redis 之前开发了很多附加组件，如时序数据扩展 Timeseries ，JSON 扩展 RedisJSON ，然后这一系列扩展统称为 Redis Stack ，所有 RedisStack 就是按 SSPL 分发的，同时保持原有的代码为 3-Clause BSD 。

> In fact, more than 50% of redis.io downloads – from Redis 6 and beyond – come from Redis Stack. We now believe that extending this licensing to Redis itself will enable us to continue to evolve the most holistic set of data models, processing engines, and developer capabilities for our users.

根据原文，他们觉得既然有超过 50% 的用户下载 Redis 都是从 Redis Stack 过来的，那为什么不把这俩合一呢？是否合理、怎么合并暂且不提，单纯因为这个原因把 core Redis 的 License 换成 RSAL+SSPL ，就纯粹是在绑架那一批完全用不到 Redis Stack 的用户了。而显然，这虽然看起来是 Redis 跟托管云的斗争，但是实际上这部分成本总会以各种形式转嫁到 end user 上。

我的桌面是 Windows ，用一对 PreSouns Eris 3.5 ，但是接了个外置声卡走的平衡输出。

XKCD 538.

https://imgs.xkcd.com/comics/security.png

介绍一下另一种形式，并非由一个 committee 来决定的形式：[终身仁慈独裁者]( https://en.wikipedia.org/wiki/Benevolent_dictator_for_life)，从 Python 之父开始的一个特定名称，被他毙掉的 PEP 不计其数。一个非常著名的提案是 PEP-572 ，就是 Python 3.8 引入的赋值（海象）操作符 `:=`，社区对这个提案一直比较两极化，但是 Guido 下场了，最终通过这个提案。

Disclaimer：我并没有说这个提案通过跟 Guido 下场有直接关系，现象如此，而且我也经常使用海象操作符。

将一个接口 wrap 进一个 db transaction 本身只保证了 db 操作的“原子性”，这还建立在本身 db 的 txn 处于正确的 isolation level 下。

所谓的接口原子性要考虑的问题远比这个复杂，如果使用了其他的后端服务，诸如 Redis 写入、第三方系统 API 调用，当非原子操作产生时，这些服务是否均支持回滚？是否保证回滚时的一致性？这样就需要从业务逻辑去考虑，然后落实到技术层面去解决，比如 Redis 是否需要 transaction 去配合？对于不支持原子的操作技术上如何取消？无法取消的事务如何在业务跟技术层面去做补偿？

我可能是极少数买了 Mathematica for Home&Hobby 的，今年他把 Cloud access 整合之后估计就继续按年续 Service plan 了

目前主用 rye ，只能说非常舒服

@lxdlam 当然，进阶还有更多话题，比如备份经常还有可能备份错，所以多天 snapshot 之类做回滚也是常见需求；根据 321 原则，是否在合理价格内支持两地、多地同步 etc ，这些大部分也都会算在成本点里面

感觉很多东西楼主没考虑到：

- 流量费用如何计算？ Ingress 跟 Egress 各自怎么计算？
- SLA 如何保证？数据取回是否会有延迟？全球上传和下载平均速度如何？
- 安全和合规如何保证？不是所有人、所有存储方案都适合用 borg ，如果直接使用 S3 跟 WebDAV etc ，平台怎么保证安全性？如果有监管部门审计需求会如何响应？

在加密备份领域业界最好的方案应该是 Tarsnap ，当然也不便宜；跟你这个方案类似的是 rsync.net ，他们提供的安全性和方式支持非常完善，供参考。

并没有找工作，只是很好奇一件事：你们对 Elixir 的态度如何？