Question

我有一个非常简单的查询，它使用json数据加入主表：

WITH
  timecode_range AS
  (
    SELECT
      (t->>'table_id')::integer AS table_id,
      (t->>'timecode_from')::bigint AS timecode_from,
      (t->>'timecode_to')::bigint AS timecode_to
    FROM (SELECT '{"table_id":1,"timecode_from":19890328,"timecode_to":119899328}'::jsonb t) rowset
  )
SELECT n.*
FROM partition.json_notification n
INNER JOIN timecode_range r ON n.table_id = r.table_id AND n.timecode > r.timecode_from AND n.timecode <= r.timecode_to

当“timecode_range”仅返回1条记录时，它可以正常工作：

Nested Loop  (cost=0.43..4668.80 rows=1416 width=97) (actual time=0.352..0.352 rows=0 loops=1)
  CTE timecode_range
    ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1)
  ->  CTE Scan on timecode_range r  (cost=0.00..0.02 rows=1 width=20) (actual time=0.007..0.007 rows=1 loops=1)
  ->  Index Scan using json_notification_pkey on json_notification n  (cost=0.42..4654.61 rows=1416 width=97) (actual time=0.322..0.322 rows=0 loops=1)
        Index Cond: ((timecode > r.timecode_from) AND (timecode <= r.timecode_to))
        Filter: (r.table_id = table_id)
Planning time: 2.292 ms
Execution time: 0.665 ms

但是当我需要返回几条记录时：

WITH
  timecode_range AS
  (
    SELECT
      (t->>'table_id')::integer AS table_id,
      (t->>'timecode_from')::bigint AS timecode_from,
      (t->>'timecode_to')::bigint AS timecode_to
    FROM (SELECT json_array_elements('[{"table_id":1,"timecode_from":19890328,"timecode_to":119899328}]') t) rowset
  )
SELECT n.*
FROM partition.json_notification n
INNER JOIN timecode_range r ON n.table_id = r.table_id AND n.timecode > r.timecode_from AND n.timecode <= r.timecode_to

它开始使用顺序扫描并且执行时间急剧增长:(

Hash Join  (cost=7.01..37289.68 rows=92068 width=97) (actual time=418.563..418.563 rows=0 loops=1)
  Hash Cond: (n.table_id = r.table_id)
  Join Filter: ((n.timecode > r.timecode_from) AND (n.timecode <= r.timecode_to))
  Rows Removed by Join Filter: 14444
  CTE timecode_range
    ->  Subquery Scan on rowset  (cost=0.00..3.76 rows=100 width=32) (actual time=0.233..0.234 rows=1 loops=1)
          ->  Result  (cost=0.00..0.51 rows=100 width=0) (actual time=0.218..0.218 rows=1 loops=1)
  ->  Seq Scan on json_notification n  (cost=0.00..21703.36 rows=840036 width=97) (actual time=0.205..312.991 rows=840036 loops=1)
  ->  Hash  (cost=2.00..2.00 rows=100 width=20) (actual time=0.239..0.239 rows=1 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 9kB
        ->  CTE Scan on timecode_range r  (cost=0.00..2.00 rows=100 width=20) (actual time=0.235..0.236 rows=1 loops=1)
Planning time: 4.729 ms
Execution time: 418.937 ms

我做错了什么？

Answer 1

PostgreSQL无法估计从表函数返回的行数，因此它使用ROWS中指定的CREATE FUNCTION值（默认为1000）。

对于json_array_elements，此值设置为100：

SELECT prorows FROM pg_proc WHERE proname = 'json_array_elements';
┌─────────┐
│ prorows │
├─────────┤
│     100 │
└─────────┘
(1 row)

但在你的情况下，该函数只返回1行。

这种错误使得PostgreSQL选择另一种连接策略（散列连接而不是嵌套循环），这会导致更长的执行时间。

如果你可以选择一些其他构造而不是PostgreSQL可以估计的这样一个表函数（例如VALUES语句），你将得到一个更好的计划。

另一种方法是，如果可以安全地指定上限，则在CTE定义中使用LIMIT子句。

如果您认为PostgreSQL在切换到超出特定行数的散列连接时出错，您可以按如下方式进行测试：

运行查询（使用顺序扫描和散列连接）并测量持续时间（psql的{{1}}命令将有所帮助）。
强制嵌套循环连接：
```
\timing
```
再次运行查询（使用嵌套循环连接）并测量持续时间。

如果PostgreSQL确实是错误的，您可以通过将SET enable_hashjoin=off; SET enable_mergejoin=off;降低到接近random_page_cost的值来调整优化器参数。

Postgresql对索引列的查询非常慢

1 个答案: