database - Postgres Materialize 导致删除查询性能不佳

Question

我有一个 DELETE 查询需要在 PostgreSQL 9.0.4 上运行。我发现它在子选择查询中达到 524,289 行之前是高性能的。

例如，在 524,288 处没有使用物化 View ，成本看起来相当不错:

explain DELETE FROM table1 WHERE pointLevel = 0 AND userID NOT IN
(SELECT userID FROM table2 fetch first 524288 rows only);
                                                QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Delete  (cost=13549.49..17840.67 rows=21 width=6)
   ->  Index Scan using jslps_userid_nopt on table1  (cost=13549.49..17840.67 rows=21 width=6)
         Filter: ((NOT (hashed SubPlan 1)) AND (pointlevel = 0))
         SubPlan 1
           ->  Limit  (cost=0.00..12238.77 rows=524288 width=8)
                 ->  Seq Scan on table2  (cost=0.00..17677.92 rows=757292 width=8)
(6 rows)

However, as soon as I hit 524,289, the materialized view comes into play and the DELETE query becomes much more costly:

explain DELETE FROM table1 WHERE pointLevel = 0 AND userID NOT IN
(SELECT userID FROM table2 fetch first 524289 rows only);

  QUERY PLAN

-----------------------------------------------------------------------------------------------------------  
Delete  (cost=0.00..386910.33 rows=21 width=6)
    ->  Index Scan using jslps_userid_nopt on table1  (cost=0.00..386910.33 rows=21 width=6)
         Filter: ((pointlevel = 0) AND (NOT (SubPlan 1)))
         SubPlan 1
           ->  Materialize  (cost=0.00..16909.24 rows=524289 width=8)
                 ->  Limit  (cost=0.00..12238.79 rows=524289 width=8)
                       ->  Seq Scan on table2  (cost=0.00..17677.92 rows=757292 width=8) (7 rows)

I worked around the issue by using a JOIN in the sub-select query instead:

SELECT s.userid 
FROM table1 s 
LEFT JOIN table2 p ON s.userid=p.userid
WHERE p.userid IS NULL AND s.pointlevel=0

但是，我仍然有兴趣了解为什么物化会如此显着地降低性能。

Answer 1

我的猜测是在 rows=524289 处内存缓冲区已满，因此必须在磁盘上具体化子查询。因此所需时间急剧增加。

在这里您可以阅读更多关于配置内存缓冲区的信息:http://www.postgresql.org/docs/9.1/static/runtime-config-resource.html
如果您使用 work_mem，您将看到查询行为的不同。

然而，在子查询中使用连接是加快查询速度的更好方法，因为您限制了源本身的行数，而不是简单地选择第一个 XYZ 行然后执行检查。