我有两个功能相同的查询。其中一个表现很好,另一个表现很差。我看不出性能差异出现在哪里。
查询#1:
SELECT id FROM subsource_position WHERE id NOT IN (SELECT position_id FROM subsource)
这回来了以下计划:
QUERY PLAN ------------------------------------------------------------------------------- Seq Scan on subsource_position (cost=0.00..362486535.10 rows=128524 width=4) Filter: (NOT (SubPlan 1)) SubPlan 1 -> Materialize (cost=0.00..2566.50 rows=101500 width=4) -> Seq Scan on subsource (cost=0.00..1662.00 rows=101500 width=4)
查询#2:
SELECT id FROM subsource_position EXCEPT SELECT position_id FROM subsource;
计划:
QUERY PLAN ------------------------------------------------------------------------------------------------- SetOp Except (cost=24760.35..25668.66 rows=95997 width=4) -> Sort (cost=24760.35..25214.50 rows=181663 width=4) Sort Key: "*SELECT* 1".id -> Append (cost=0.00..6406.26 rows=181663 width=4) -> Subquery Scan on "*SELECT* 1" (cost=0.00..4146.94 rows=95997 width=4) -> Seq Scan on subsource_position (cost=0.00..3186.97 rows=95997 width=4) -> Subquery Scan on "*SELECT* 2" (cost=0.00..2259.32 rows=85666 width=4) -> Seq Scan on subsource (cost=0.00..1402.66 rows=85666 width=4) (8 rows)
我有一种感觉,我缺少对我的一个查询显然不好的东西,或者我错配了Postgresql服务器。我本来希望这不会优化;是不是总是一个性能问题,还是有原因呢这里没有优化?
附加数据:
=> select count(*) from subsource; count ------- 85158 (1 row) => select count(*) from subsource_position; count ------- 93261 (1 row)
编辑:我现在已经修复了下面提到的A-B!= B-A问题。但是我的问题仍然存在:查询#1仍然比查询#2大得多。据我所知,这两个表的行数相似。
编辑2:我使用Postgresql 9.0.4。我无法使用EXPLAIN ANALYZE,因为查询#1需要太长时间。所有这些列都不为空,因此应该没有区别。
由于您使用默认配置运行,请尝试重新启动work_mem。很可能,子查询最终会被假脱机到磁盘,因为您只允许1Mb的工作内存。尝试10或20mb。