@mark2025 这可能有点夸张，有前同事去 zilliz 说 Milvus + cuda 会比 pgvector 快的....

不过话说回来 PG 是我所看过的数据库中，个人认为写的最好的，代码质量相当高。

@mark2025 PG hook 多，extension 好做，社区很壮大，即使 PG 本身不带的功能，社区总是能找到 extension 做过了的。

如果是二房东/公寓管理房租的，那么看看能不能换一套？

@sockpuppet9527 #18 另外想补充一些，目前应该知名一些的开源项目都是需要每一个 PR 进行 review 的。

@huyangq #13

如果读的顺畅了，那速度会很快。跑 case 的话，我有个环境专门来验 case ，一套脚本拉下来+编译+跑 case 10~20 分钟左右。

目前我工作上做 code review 时间大概是 2 ~ 3 成左右，我之前同事，某个开源的 maintainer ，他的 code review 时间大概要占在 5 成左右。基本年长一些的同事都是占这个值。

我个人是拥护 code review 的，code review 带来的好处是去追赶进度/盲目重构不可比的。

1. code review 的流程

我本人做 code review ，得细分看什么类型的 pr ，如果是 fix 类的 pr ，那么只做逻辑上的验证即可。
但如果是 feature 类的 pr ，会先把 branch 拉下来，看本身测试 case 跑一下。然后找到"入口"，一般来说都是接口，如果不是接口，那么回想着能不能改成接口？

有了"入口"之后，那么基本就是接口->实现->调用者这样去看，我会一行行读，主要看几个方面
- 当前接口在哪个层级？放得位置是否合理？抽象接口做的是否足够合理？
- 实现函数是否合理？注释/命名是否符合目前的 code style ？参数和返回是否能改的更合理？
- 当前实现逻辑是否正确？是否存在风险？参数有无验证？
- 是否存在极端 case 出现问题？

当然还有很多，一时半会可能总结不出来，但如果你让别人多 review 你的代码，你也能找到自己的经验

2. code review 的频率

每个 PR

@kinsou 好的，感谢，我再忍忍

@fredsunme 对，但独立 ip 不开东西就能很安稳。成本并不算是很高

真的不推荐 TMS ，前段时间才锁了 +086 。当然你实在要玩，台湾电话卡 100+ 一年（可以找几个 TMS 群/NGA 找找看）。

推荐 GMSR ，GMSR 现在大斗燃+3 个 149 斗燃。外挂也比 TMS 少，我玩了半个月 GSMR ，感觉还不错。

三年了，LZ 还没找到吗？

myprotein + 1

《水果篮子》 《魔法咪路咪路》

对称加密要做 round function 置换的，在没有 key 的情况下，初始值是啥都不知道。

有 key 的话，AI 推导出来，是存在一定可能性的