我有两个功能相同的查询.其中一个表现很好,另一个表现很差.我看不出性能差异是从哪里产生的.
问题#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 server.我本以为这NOT IN
个会很好地优化;NOT IN
始终是一个性能问题,还是它没有在这里优化的原因?
其他数据:
=> select count(*) from subsource;
count
-------
85158
(1 row)
=> select count(*) from subsource_position;
count
-------
93261
(1 row)
Edit:我现在已经修好了A-B!=下面提到的一个问题.但我所说的问题仍然存在:查询#1仍然比查询#2严重得多.我认为,这是因为两个表的行数相似.
Edit 2:我正在使用PostgresQL 9.0.4.我无法使用EXPLAIN Analysis,因为查询#1需要的时间太长.所有这些列都不是空的,因此应该没有什么不同.
Edit 3:这两列我都有索引.我还没有完成查询#1(约10分钟后放弃).查询#2立即返回.