postgresql也很强大，为何在中国，mysql成为主流，postgresql屈居二线呢？

普通人用pg会碰到稀奇古怪的障碍，一气之下就退回mysql了呗。我的一个小项目就很能说明这一点：

这是我弄的一个人练手项目，自动从贴吧采集图片做成梗图视频发抖音。用数据库来存图片及其对应tensor，并用cos相似度去重。

最开始用的是mysql，但当表来到1t左右，由于每张图片都要全表扫相似度，添加图片变得特别特别慢。当然这是算法本身的问题，但是抛开这些，select、update本身的性能下降也是肉眼可见的。

是是是，我知道向量搜索用fasis或者es会好很多，但我这毕竟是小项目不想把东西放的东一块西一块的。于是我决定跳坑pg。用上pgvector插件提供的相似度索引后，一切变得非常丝滑。基于同样的缘由我也不想把图片和相应信息分开放。

<>直到我单表体积到了3.6T

我一看我硬盘空间要没了，那么把打分低的图片都删掉呗。

然后我碰见了第一个不可理喻的事情：

删除速率极低，1秒5条！

然而explainyze后发现Plan阶段是瞬间完成的。

但是这难不倒程序员嘛，我tmux跑了个分atch删除的脚本睡觉去了。

起来一看，令我震惊的事情发生了：

<>删掉了80%的条目后，占用空间一点没降！

于是我赶紧谷歌，发现原来pg的删除原来只是简单标记了下，需要vacuum才能删除。

那就vacuum呗。然后我发现过程中表几乎无法被访问，只好暂停了所有任务，跑了快2天才把vacuum跑完。为了让腾空间立即起效我还冒险删掉了zfs所有快照。

然后我震惊的发现：

vacuum完后体积一点没降！

这tmd就说不通，可能的解释是pg保存了删除的事务志以供还原，但我tmd哪里等得起，vacuumfull走起。

结果你大概猜的到：

vacuumfull跑了一半就因为用光了所有空间失败了

这tm简直难以理喻，毕竟新表才200g而我还有900g空闲空间。

我谷歌半天后，得到的结论是：TMvacuumfull也给删除写了一大堆事务志，于是就爆了。

最后我只能新建了一个表，用脚本完成了数据迁移。

你以为这就结束了？

！

写了个脚本每天自动删重复图片后，我也以为事情就结束了，但没过几天我又双叒叕震惊的发现：

update怎么极慢

经过一番谷歌后我发现：原来pg的update就是删除再。于是简单变更个pulished字段就相当于把昂贵的tensor再重新一边。

而且我发现setpulished_ut_reuseale=idinany(%s)的方式，速度远慢于我直接更新那几个id。合着优化器根本没优化呗。那岂不是相当于天天反复插全表？我每天1快照存着都没爆空间得感谢zfs去重功能做得好。

麻了，那就改呗，丧失点容错性我还能。

你以为这就完了？

！

为了改这些我熬了好几夜，惊奇的发现每到0点数据库就卡到读不出来数据，弄得我还以为是查询写呲了。

你猜这么着？autovacuum！！！而且：

就200g数据autovacuum一跑就1个小时，每天来一次，期间业务基本都跑不了！

我承认我在nas上部署d性能是不好，但也不至于此啊，sqlite都没这么差吧！

最后我就非常识趣的圆润回mysql了，大不了不做去重了！

（有些结论是熬夜时得出的，现在回看可能受到了autovacuum的影响。如果被误导了别骂我，直接打骂这个雷打不动1小时的autovacuum去）