postgresql也很强大，为何在中国，mysql成为主流，postgresql屈居二线呢？
普通人用pg会碰到稀奇古怪的障碍，一气之下就退回mysql了呗。我的一个小项目就很能说明这一点：
这是我弄的一个人练手项目，自动从贴吧采集图片做成梗图视频发抖音。用数据库来存图片及其对应tensor，并用cos相似度去重。
最开始用的是mysql，但当表来到1t左右，由于每张图片都要全表扫相似度，添加图片变得特别特别慢。当然这是算法本身的问题，但是抛开这些，select、update本身的性能下降也是肉眼可见的。
<>直到我单表体积到了3.6T
我一看我硬盘空间要没了，那么把打分低的图片都删掉呗。
然后我碰见了第一个不可理喻的事情：
删除速率极低，1秒5条！
但是这难不倒程序员嘛，我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去）
