PostgreSQL: нет сокращения раздела при инициализации плана запроса с LATERAL JOIN и агрегатами - PullRequest
Новая
       13

PostgreSQL: нет сокращения раздела при инициализации плана запроса с LATERAL JOIN и агрегатами

1 голос
/ 21 января 2020

Интересно, почему удаление разделов не работает с LATERAL JOIN и агрегатами. Ниже приведен мой пример, протестированный на PostgreSQL 12.1 (Ubuntu 12.1-1.pgdg18.04 + 1): 

CREATE TABLE demo(key BIGINT) PARTITION BY LIST (key);
CREATE TABLE demo_key_1 PARTITION OF demo FOR VALUES IN (1);
CREATE TABLE demo_key_2 PARTITION OF demo FOR VALUES IN (2);
INSERT INTO demo(key) VALUES (1), (2);
ANALYZE demo;



CREATE TABLE demo2(key BIGINT) PARTITION BY LIST (key);
CREATE TABLE demo2_key_1 PARTITION OF demo2 FOR VALUES IN (1);
CREATE TABLE demo2_key_2 PARTITION OF demo2 FOR VALUES IN (2);
INSERT INTO demo2(key) VALUES (1), (2);
ANALYZE demo2;

Теперь, если в SELECT в LATERAL JOIN нет агрегатов, все работает как положено - сканируется только один раздел каждой таблицы: 

EXPLAIN ANALYZE
         SELECT * FROM demo
         JOIN LATERAL (
                  SELECT key AS key2
                  FROM demo2
                  WHERE demo2.key = demo.key
         ) d ON TRUE
         WHERE demo.key = 1;
                                                QUERY PLAN
-----------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=0.00..2.03 rows=1 width=16) (actual time=0.007..0.008
rows=1 loops=1)
   ->  Seq Scan on demo_key_1  (cost=0.00..1.01 rows=1 width=8) (actual
time=0.004..0.005 rows=1 loops=1)
         Filter: (key = 1)
   ->  Seq Scan on demo2_key_1  (cost=0.00..1.01 rows=1 width=8) (actual
time=0.001..0.001 rows=1 loops=1)
         Filter: (key = 1)
 Planning Time: 0.191 ms
 Execution Time: 0.025 ms
(7 rows)

Однако, когда я пытаюсь выполнить очень похожий запрос, содержащий функцию агрегирования, разделы demo2 не удаляются из плана запроса: 

EXPLAIN ANALYZE
         SELECT * FROM demo
         JOIN LATERAL (
                  SELECT sum(demo2.key) AS sum2
                  FROM demo2
                  WHERE demo2.key = demo.key
         ) d ON TRUE
         WHERE demo.key = 1;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=2.03..3.07 rows=1 width=40) (actual time=0.018..0.018
rows=1 loops=1)
   ->  Seq Scan on demo_key_1  (cost=0.00..1.01 rows=1 width=8) (actual
time=0.005..0.005 rows=1 loops=1)
         Filter: (key = 1)
   ->  Aggregate  (cost=2.03..2.04 rows=1 width=32) (actual
time=0.011..0.011 rows=1 loops=1)
         ->  Append  (cost=0.00..2.03 rows=2 width=8) (actual
time=0.004..0.005 rows=1 loops=1)
               ->  Seq Scan on demo2_key_1  (cost=0.00..1.01 rows=1
width=8) (actual time=0.002..0.002 rows=1 loops=1)
                     Filter: (key = demo_key_1.key)
               ->  Seq Scan on demo2_key_2  (cost=0.00..1.01 rows=1
width=8) (never executed)
                     Filter: (key = demo_key_1.key)
 Planning Time: 0.174 ms
 Execution Time: 0.082 ms
(11 rows)

Конечно, Seq Scan на demo2_key_2 никогда не выполнялся, но почему он не был удален из плана запроса? Это усложняет более сложные запросы с сотнями разделов.

Обходной путь - добавить избыточное условие в подзапрос: 

EXPLAIN ANALYZE
         SELECT * FROM demo
         JOIN LATERAL (
                  SELECT sum(demo2.key) AS sum2
                  FROM demo2
                  WHERE demo2.key = 1 AND demo2.key = demo.key
         ) d ON TRUE
         WHERE demo.key = 1;
                                                      QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------
 Nested Loop  (cost=1.01..2.05 rows=1 width=40) (actual time=0.011..0.011
rows=1 loops=1)
   ->  Seq Scan on demo_key_1  (cost=0.00..1.01 rows=1 width=8) (actual
time=0.004..0.004 rows=1 loops=1)
         Filter: (key = 1)
   ->  Aggregate  (cost=1.01..1.02 rows=1 width=32) (actual
time=0.006..0.006 rows=1 loops=1)
         ->  Result  (cost=0.00..1.01 rows=1 width=8) (actual
time=0.002..0.002 rows=1 loops=1)
               One-Time Filter: (demo_key_1.key = 1)
               ->  Seq Scan on demo2_key_1  (cost=0.00..1.01 rows=1
width=8) (actual time=0.001..0.002 rows=1 loops=1)
                     Filter: (key = 1)
 Planning Time: 0.079 ms
 Execution Time: 0.031 ms
(10 rows)

1 Ответ

1 голос
/ 21 января 2020

Оптимизатор не достаточно умен, чтобы сделать вывод, что он может пропустить раздел. Но поскольку в версии 12 выполняется сокращение раздела во время выполнения, проверка раздела пропускается исполнителем.

Это не должно оказывать заметного негативного влияния на производительность запроса.

Существует ограничение в умность оптимизатора. Лучше всего использовать простые условия, если вы хотите сократить раздел.

...