Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Дата
Msg-id CAApHDvrYij__F-5-ZNeCgifa-JrTh6zkdqZG6kN31rQu=yLTJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions  (Dimitrios Apostolou <jimis@gmx.net>)
Список pgsql-general
On Tue, 14 May 2024 at 02:07, Dimitrios Apostolou <jimis@gmx.net> wrote:
>
> On Tue, 14 May 2024, David Rowley wrote:
> > Parallel Append can also run in a way that the Append child nodes will
> > only get 1 worker each.
>
> How can I tell which case it is, from the EXPLAIN output (for example
> the output at [1]) ?

IIRC, the planner does prefer to use Parallel aware child Paths when
creating a Parallel Append.  Given equivalent costs, there's no
advantage to it choosing a non-parallel aware Path.  The planner does
not have any optimisations that that would enable.  However, it is
possible that the planner *could* generate these. All the Append
subpaths would just have to all be parallel safe but not parallel
aware. You could identify them in EXPLAIN by seeing a "Parallel
Append" without the "Parallel" in front of the node names in any of
the Parallel Append's subpaths.

David



В списке pgsql-general по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: how to completely turn off statement error logging