@laminux29 gin 是倒排索引，分词是另外的东西

@laminux29 #11 gin index 了解一下 https://www.postgresql.org/docs/current/gin.html

不听音乐上不了这个班的，必须得一遍听音乐一边写代码

给过天翼云做项目，大甲方的公司。

个人还是觉得不要去用。。

@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 不开东西就能很安稳。成本并不算是很高