интерпретация плана выполнения с лимитом и порядком

Question

У меня есть таблица test1, которая содержит 20 000 000 кортежей. Я делаю запрос на эту таблицу с заказом по пункту. Количество возвращаемых кортежей ограничено 10. Я не понимаю, почему в плане выполнения обрабатывается менее 20 000 000 кортежей, в то время как в порядке упорядочения следует анализировать всю таблицу.

demo=# explain select content from test1 order by content limit 10;
 Limit  (cost=451329.69..451330.85 rows=10 width=33)
   ->  Gather Merge  (cost=451329.69..2395909.82 rows=16666666 width=33)
         Workers Planned: 2
         ->  Sort  (cost=450329.66..471163.00 rows=8333333 width=33)
               Sort Key: content
               ->  Parallel Seq Scan on test1  (cost=0.00..270249.33 rows=8333333 width=33)
 JIT:
   Functions: 3
   Options: Inlining false, Optimization false, Expressions true, Deforming true
(9 rows)

Answer 1

Он использует параллельный план, поэтому он разделяет 20 000 000 строк тремя способами (один лидер плюс 2 работы). Однако данные делятся по блокам, а не по отдельным строкам, поэтому предполагаемое количество строк основано на множителе, предполагающем, что кто-то собирается получить их непропорционально большое количество.

На этапе объединения , он считает, что кортежи, которые, по его мнению, будут переданы рабочими, но (очевидно, я не копался в исходном коде для этого) не учитывают строки, которые, как ожидается, будет доставлен самим лидером.

Планы намного проще интерпретировать, если сначала отключить распараллеливание, set max_parallel_workers_per_gather TO 0;. Если, конечно, вы не исследуете распараллеливание, конечно.

Answer 2

Как объяснено в руководстве , количество строк, сообщаемых в «простом» выводе объяснения, составляет оценка .

Таким образом, общее количество строк в этой таблице оценивается в 16666666 (это можно увидеть в узле Gather Merge)

Postgres решил выполнить параллельное сканирование последовательности для таблицы, чтобы читать все строки. Простой explain (без каких-либо дополнительных опций) не показывает детали о параллельной части. Но предполагаемое количество строк, показанное в узле Parallel Seq Scan, составляет ровно половину от общего числа строк, оцененных для таблицы. Таким образом, вы можете предположить, что планировщик будет использовать два потока для параллельного сканирования.

Я почти уверен, что если вы запустите explain (analyze) select ..., вы увидите, что число параллельных рабочих, о которых сообщается, равно 2. Затем вы также увидите действительное количество строк, обработанных каждым рабочим ( скорее всего ровно 100000)