MIME-Version: 1.0
References: <7886a68f-b466-2131-1747-f69f0fb71a37@gmx.net> <69077f15-4125-2d63-733f-21ce6eac4f01@gmx.net>
 <559b0e40-63e6-fa9a-6b03-d1eba10f30f8@gmx.net> <1629463.1715372568@sss.pgh.pa.us>
 <6a2f3906-3d7a-6924-7403-8f77d57a18e4@gmx.net> <1685688.1715391218@sss.pgh.pa.us>
 <CAApHDvqWfGdUpTUp9s7AZYSeh44aLEXoBQS7UcfKM0zKhTCkiQ@mail.gmail.com>
 <2e3947bd-b01c-37c8-00e1-d8e925e79597@gmx.net> <CAApHDvoJHxrsgQm8cS=yWN2akxP=bLxuYNPCaXXWcmcG+_b1iw@mail.gmail.com>
 <410018fd-1f9b-41b7-6257-89844b984564@gmx.net>
In-Reply-To: <410018fd-1f9b-41b7-6257-89844b984564@gmx.net>
From: David Rowley <dgrowleyml@gmail.com>
Date: Tue, 14 May 2024 02:22:03 +1200
Message-ID: <CAApHDvrYij__F-5-ZNeCgifa-JrTh6zkdqZG6kN31rQu=yLTJw@mail.gmail.com>
Subject: Re: SELECT DISTINCT chooses parallel seqscan instead of indexscan on
 huge table with 1000 partitions
To: Dimitrios Apostolou <jimis@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAApHDvrYij__F-5-ZNeCgifa-JrTh6zkdqZG6kN31rQu%3DyLTJw%40mail.gmail.com>
Precedence: bulk

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