加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

PostgreSQL:NOT IN与EXCEPT性能差异(编辑#2)

发布时间:2020-12-13 16:39:58 所属栏目:百科 来源:网络整理
导读:我有两个功能相同的查询。其中一个表现很好,另一个表现很差。我看不出性能差异出现在哪里。 查询#1: SELECT id FROM subsource_positionWHERE id NOT IN (SELECT position_id FROM subsource) 这回来了以下计划: QUERY PLAN ----------------------------
我有两个功能相同的查询。其中一个表现很好,另一个表现很差。我看不出性能差异出现在哪里。

查询#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需要太长时间。所有这些列都不为空,因此应该没有区别。

编辑3:我在这两列上有一个索引。我还没有得到第1号查询完成(约10分钟后放弃)。查询#2立即返回。

由于您使用默认配置运行,请尝试重新启动work_mem。很可能,子查询最终会被假脱机到磁盘,因为您只允许1Mb的工作内存。尝试10或20mb。

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读