postgresql 为什么这么慢

[a002269]

select count(*) from t_table1 as t1 where （或 not） exists (select null from t_table2 as t2 where t2.user_id = t1.user_id)

同样的条件，同样2500万条记录。

为什么mssql，1秒就出结果了
而 postgresql 要 120 才出结果？

[吉普赛的歌]

SELECT COUNT(*)
FROM   t_table1 AS t1
WHERE  EXISTS (
           SELECT NULL
           FROM   t_table2 AS t2
           WHERE  t2.user_id = t1.user_id
)
--1. Postgresql 中 t1, t2 的数据量与SQL Server中数据量一致？
--2. Postgresql 中 t1, t2 中有没有为 user_id 建议索引？

[a002269]

肯定都是一致的，也都是有索引的。

[OwenZeng_DBA]

引用 楼主 a002269 的回复:

select count(*) from t_table1 as t1 where （或 not） exists (select null from t_table2 as t2 where t2.user_id = t1.user_id) 同样的条件，同样2500万条记录。 为什么mssql，1秒就出结果了 而 postgresql 要 120 才出结果？

虽然，我很想说大微软数据库太牛逼了，，，但是这个几个数据库的差距没那么大，，关键还是看怎么用，是不是某些设置有不对的地方

[吉普赛的歌]

postgresql 中的user_id索引都改成聚集的看看

[a002269]

没啥用，我看他的查询计划，居然不走索引。。。。不知道他怎么想的，通过修改配置文件，让他走索引。就算这样还要12秒，mssql随便怎么搞，not in not exists 什么都不用考虑，基本上一两秒也就出结果了。两份数据是完全一样的，也都是重启服务后测试的。。。。count这东西在postgresql上怎么都快不了感觉。。。

[吉普赛的歌]

引用 5 楼 a002269 的回复:

没啥用，我看他的查询计划，居然不走索引。。。。不知道他怎么想的，通过修改配置文件，让他走索引。就算这样还要12秒，mssql随便怎么搞，not in not exists 什么都不用考虑，基本上一两秒也就出结果了。两份数据是完全一样的，也都是重启服务后测试的。。。。count这东西在postgresql上怎么都快不了感觉。。。

强制让它走索引呢？

[吉普赛的歌]

引用 11 楼 zjcxc 的回复:

这就是发动机不好导致的结果 postgresql 不熟，不说评价，但 mysql 和 mssql 做这种比较的话，mysql 一样完败

count一般用于分页， mysql用上found_rows和记录一起出结果也不比SQL Server差吧？

[zjcxc]

引用 12 楼 yenange 的回复:

[quote=引用 11 楼 zjcxc 的回复:] 这就是发动机不好导致的结果 postgresql 不熟，不说评价，但 mysql 和 mssql 做这种比较的话，mysql 一样完败

count一般用于分页， mysql用上found_rows和记录一起出结果也不比SQL Server差吧？[/quote] 能利用一些特性的处理的情况不管，毕竟不是任何地方都能用到的

[学海无涯-回头是岸]

不同数据库 差距这么大啊？ 那他咋活下来哦

[a002269]

Finalize Aggregate (cost=16045703.63..16045703.64 rows=1 width=8) -> Gather (cost=16045703.41..16045703.62 rows=2 width=8) Workers Planned: 2 -> Partial Aggregate (cost=16044703.41..16044703.42 rows=1 width=8) -> Merge Join (cost=1.14..16021129.95 rows=9429387 width=0) Merge Cond: (t1.user_id = t2.user_id) -> Parallel Index Only Scan using t_table1_user_id_idx on t_table1 t1 (cost=0.56..15898680.48 rows=9429387 width=8) -> Index Only Scan using t_table2_pkey on t_table2 t2 (cost=0.29..4519.67 rows=31277 width=8)

[a002269]

引用 6 楼 yenange 的回复:

[quote=引用 5 楼 a002269 的回复:] 没啥用，我看他的查询计划，居然不走索引。。。。不知道他怎么想的，通过修改配置文件，让他走索引。就算这样还要12秒，mssql随便怎么搞，not in not exists 什么都不用考虑，基本上一两秒也就出结果了。两份数据是完全一样的，也都是重启服务后测试的。。。。count这东西在postgresql上怎么都快不了感觉。。。

强制让它走索引呢？[/quote] 走索引12秒，反正要count的他都是扫全部，全表或全索引

[吉普赛的歌]

引用 8 楼 a002269 的回复:

走索引12秒，反正要count的他都是扫全部，全表或全索引

查了下， count 确实是 postgresql 的软肋， 很多人都是用触发器在曲线救国。 另外，如果你这两个表的增删改不是那么频繁的话，推荐你尝试一下 物化视图。

[zjcxc]

这就是发动机不好导致的结果 postgresql 不熟，不说评价，但 mysql 和 mssql 做这种比较的话，mysql 一样完败

[吉普赛的歌]

引用 14 楼 a002269 的回复:

放到服务器上去测试了，5千万数据，16核32线，96G内存，pg开启并发查询，速度基本上可以了，但是还是比ms慢，不管是走索引还是扫全表，基本上在1秒到几秒左右，基本上可以接受了。 我也是刚从ms转到pg去的，也不说什么了。。。。 不过数据库占用的空间倒是只有ms的一半，给我省了很多SSD的钱。

能用就好， 没事就结贴吧

[a002269]

放到服务器上去测试了，5千万数据，16核32线，96G内存，pg开启并发查询，速度基本上可以了，但是还是比ms慢，不管是走索引还是扫全表，基本上在1秒到几秒左右，基本上可以接受了。 我也是刚从ms转到pg去的，也不说什么了。。。。 不过数据库占用的空间倒是只有ms的一半，给我省了很多SSD的钱。