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

From Tom Lane
Subject Re: Parallel Append can break run-time partition pruning
Date
Msg-id 9565.1587598749@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallel Append can break run-time partition pruning  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Parallel Append can break run-time partition pruning  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes:
> On Thu, 23 Apr 2020 at 11:11, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

Right, so really the costs of partial and non-partial paths are not
commensurable, and comparing them directly is just misleading.
I trust we're not throwing away non-partial paths on that basis?

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Parallel Append can break run-time partition pruning
Next
From: Jesse Zhang
Date:
Subject: Re: Header / Trailer Comment Typos for M4 macros