正文：
天上的“PostgreSQL” 说 地上的 PostgreSQL 都是“小垃圾”
云数据库核爆在内部，上云下云话题都是皮外伤！--2025云数据库专栏（二）
上次那篇说PostgreSQL"垃圾”的文章，爆表了，算是第一次核爆，如同我所讲，其实手里还有一颗核弹，不是不爆，时候未到，时候一到，全部核爆。今天的标题更有意思，
宇宙中的“postgreSQL” 说地球上的 “PostgreSQL” 都是“小垃圾”。 其实大家都是朋友,同事，什么垃圾不垃圾，打打杀杀的还是别在明面上。
但是，在大部分数据库都在往超融合类的数据库前进，比如OB，TIDB，POLARDB，TDSQL，ORACLE，SQL SERVER ，这一众的数据库都在往自己的身上插入更多的功能，同时PostgreSQL 作为开源数据库中最能往自己身上插功能的，到底OLAP的功能应不应该有，相信大家一定会有自己的观点和评论，这就如同买车都喜欢马力大的，谁也不愿意弄一个“三蹦子”搞回家，然后和别人说，嗯我不需要马力，我开三蹦子就挺好，因为我不需要四个轮，我不需要那么多马力，其实是心虚和无力的展现，看破不说破，冷暖自知。
另外这次没有duckDB的事情了，致敬也好，抄袭也罢，和“鸭子”这次是没关系了，这次既不致敬，也不抄袭，
（其实说到抄袭，如果人类杜绝了“抄袭”，那就没有另一个词汇，“学习”，明白的人都懂，发展就是要学习，就是要取长补短，否则自己关门自己干自己的1000年，一出门刚想说我发明的马车，一看人家都到宇宙飞船了，聪明的人都会学习，取长补短，辩证看问题，做一个清醒者）
，也不青出于蓝胜于蓝了，这次我们彻底换sai,“橙色”，
其实我早就想到那篇文章一出，冯老师的跳起来，“找我算账”，可惜了，晚了。在冯老师跳起来之前，早了5个小时，已经有人找我了，就是那个宇宙的PostgreSQL，也是今天另一个核弹，宇宙的"PostgreSQL". PolarDB for PostgreSQL 商业版。
人家声称，线下的必然是垃圾，天上的也是“垃圾”，咱们这是宇宙的"PostgreSQL",我就问，你有啥本事，人家postgresql +duckdb 是 OLAP + OLTP 的解决方案，人家 RDS POSTGRESQL 是内嵌DUCKDB 无损化的解决方案，难道你还逆天，我听听你咋个逆天法，他说完我沉默了，你们行呀，卷吧，来你们看看，卷不卷，这个地球外的"POSTGRESQL"。
他们给我总结的几个特点：
1 云原生数据库解决数据库OLAP + OLTP 在PolarDB for PostgreSQL中根本不用增加节点，说我那篇文章误导别人。
2 云原生数据库解决列式问题，根本不用新建表，说RDS不行。自建的ECS postgreSQL + DuckDB 那也叫个东西，什么玩意。
3 他们解决问题只需要三步
1 打开POLARDB FOR PG的向量引擎
2 对需要进行列计算的表建立列索引
3 执行语句
此时你的POLARDB FOR PostgreSQL 就变成 OLAP + OLTP的数据库，且更灵活，只需要建立一个索引表就变成列式数据+行数据并存了，他们说 “我们说POSTGRESQL + DUCK_DB 是小垃圾有错吗？那么多零碎你累不累“ ，“ 他们说 那RDS POSTGRESQL 还的新建表， 是小垃圾有错吗？”
（画外音，RDS POSTGRESQL 说那不还有什么都没有的吗？ 我们已经比开源POSTGRESQL 强多了）
好嘛，你们都厉害，你们都不垃圾，我是小垃圾，小呀小邋遢，邋遢大王就是我，小呀小邋遢。这次我是捅了马蜂窝了，逼着我非要也给做一个测试，好咱们公平，也来给POALRDB FOR POSTGRESQL 列式做测试。
1步，打开POALRDB FOR POSTGRESQL
2步，安装列式引擎插件polar_csi
3步，在数据库上插入polar_csi
4步，建立csi索引
马上查询，马上列式CSI。
polar_pg=> select version(); version -------------------------------------------------------------------------- PostgreSQL 14.13 (PolarDB 14.13.28.0 build ba5b411d) on x86_64-linux-gnu (1 row) Time: 7.564 ms polar_pg=> create extension polar_csi; CREATE EXTENSION Time: 14.178 ms polar_pg=> polar_pg=> polar_pg=> polar_pg=> CREATE TABLE sales ( polar_pg(> sale_id UUID PRIMARY KEY DEFAULT gen_random_uuid(), polar_pg(> name CHAR(200), polar_pg(> amount INT polar_pg(> ); CREATE TABLE Time: 14.365 ms polar_pg=> polar_pg=> polar_pg=> INSERT INTO sales (sale_id, name, amount) polar_pg-> SELECT polar_pg-> gen_random_uuid(), -- 同上 polar_pg-> TO_CHAR(TRUNC(RANDOM() * 10^6), '0000000000' ), polar_pg-> ROUND(RANDOM() * 10000 - 5000) polar_pg-> FROM generate_series(1, 10000000); INSERT 0 10000000 Time: 148960.140 ms (02:28.960) polar_pg=> polar_pg=> polar_pg=> create index csi_index_name_amount on sales using csi(sale_id,name,amount); CREATE INDEX Time: 177093.429 ms (02:57.093) polar_pg=> polar_pg=> SET polar_csi.enable_query = off; SET Time: 6.702 ms polar_pg=> select count(*) from sales; count ---------- 10000000 (1 row) Time: 12158.817 ms (00:12.159) polar_pg=> SET polar_csi.enable_query = on; SET Time: 7.153 ms polar_pg=> select count(*) from sales; count ---------- 10000000 (1 row) Time: 934.554 ms polar_pg=>
很明显，使用了列式索引的聚合操作，934ms，而没有使用并行scan消耗了 12158ms。
这样的方案解决了如下问题
1 查询列式，行式在数据库可以随时关闭和开启
2 列式查询可以针对你要的列，而不是整体表
3 可以定制化针对某个查询在不开启列式的情况下，强制使用列式查询。
/*+ SET (polar_csi.enable_query on/off)
/ SELECT COUNT(
) FROM sales;
4 查询中如果有报表的查询可以使用最终一致性的方案来查询，同时也可以使用针对即席查询使用强制一致性的查询方式。同时即使是列式查询也可以使用并行来进行操作，有相关的参数可以
画重点，人家没有挂上DUCKDB做外挂，也不用建立另外一张表，需要的只是建立一个索引，DONE，perfect,所以人家说，你们都是“小垃圾”，且人家还可以在读写分离中，让列式索引也强一致性。
So，I have no words to them. 但我也惹不起地上和天上的PostgreSQL，最终结论，我垃圾，是那个小邋遢。
那么PolarDB for PostgreSQL 说其他的PostgreSQL都垃圾，的几个深层次的原因：
1 充分利用CPU的SIMD 单指令多数据指令集，单条指令可以处理多条数据，例如AVX-512指令集的512位寄存器可一次性处理16个单精度浮点数。这种并行性将传统循环计算的指令数减少至1/16，显著提升计算密集型任务的性能。
2 列式存储使同一列数据连续存储，提升CPU Cache命中率，列存访问的Cache命中率比行存高40%以上，连续内存布局使SIMD指令利用率提升3-5倍
3 表中可同时存在列存索引（用于向量化引擎）和B-tree/GiST索引（用于行存引擎）。 优化器根据查询类型动态选择： 分析型查询（如SELECT sum(salary) FROM employees）优先使用列存索引 事务型查询（如UPDATE employees SET salary=...）使用行存索引
另外还有一点，灵活性，因为我可以针对一些表，就一些大表建立向量索引，且针对特殊的列，这样节省空间，且给开发者，DBA的灵活处理的余地更大，更别提那一堆我到现在还在看的调优参数，且因为他的灵活性，可以让行列存在一个表里面，成本会更低，你没有必要在POSTGRESQL后再挂一个DUCKDB，也没有必要像RDS在创建一张新表，所以此时此刻他说他们垃圾，我也无法反驳。
另外还有几个点，这里就不多说了，说出来又是核爆，最近核辐射太大，我还是歇息歇息，那凉快哪里呆着去！ 你们打 你们继续，继续提高数据库的技术水平。
临时工：数据库人生路，如何救赎自己 -- 答某个迷茫DBA的职业咨询
开源软件是心怀鬼胎的大骗局 -- 开源软件是人类最好的正能量 --- 一个人的辩论会
AI 祸国殃民必须铲除，AI国强民富必须支持
PolarDB 相关文章
“PostgreSQL” 高性能主从强一致读写分离，我行，你没戏！
PostgreSQL 的搅局者问世了，杀过来了！
在被厂商围剿的DBA 求生之路 --我是老油条
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密（谁是绵羊，谁是怪兽）
在被厂商围剿的DBA 求生之路 --我是老油条
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤，来自杭州的Package
（活动结束了）
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火星人
PolarDB-MySQL 并行技巧与内幕--（怎么薅羊毛）
