Re: Parallel Append can break run-time partition pruning - Mailing list pgsql-hackers

From David Rowley
Subject Re: Parallel Append can break run-time partition pruning
Date
Msg-id CAApHDvptEEuhidhRG1bPaSmBLx6TeTjZjNJH3eZogVbjc0Z9-Q@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Append can break run-time partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parallel Append can break run-time partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Parallel Append can break run-time partition pruning  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 23 Apr 2020 at 11:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> David Rowley <dgrowleyml@gmail.com> writes:
> > Given the same set of paths, when would a non-parallel append be
> > cheaper than a parallel one?
>
> Well, anytime the parallel startup cost is significant, for starters.
> But maybe we account for that at some other point, like when building
> the Gather?

Yeah. There's no mention of parallel_setup_cost or parallel_tuple_cost
in any of the Append costing code. Those are only applied when we cost
Gather / GatherMerge At the point Amit and I are talking about, we're
only comparing two Append paths. No Gather/GatherMerge in sight yet,
so any additional costs from those is not applicable.

If there was some reason that a Parallel Append could come out more
expensive, then maybe we could just create a non-parallel Append using
the same subpath list and add_partial_path() it. I just don't quite
see how that would ever win though. I'm willing to be proven wrong
though.

David



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Parallel Append can break run-time partition pruning
Next
From: Tom Lane
Date:
Subject: Re: Parallel Append can break run-time partition pruning