From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Dimitrios Apostolou <jimis(at)gmx(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions |
Date: | 2024-05-13 14:22:03 |
Message-ID: | CAApHDvrYij__F-5-ZNeCgifa-JrTh6zkdqZG6kN31rQu=yLTJw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, 14 May 2024 at 02:07, Dimitrios Apostolou <jimis(at)gmx(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-05-13 14:26:09 | Re: how to completely turn off statement error logging |
Previous Message | David Rowley | 2024-05-13 14:15:45 | Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on huge table with 1000 partitions |