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 CAApHDvrAvsiRQs4dA2rX33gD9qpHyHmhgk3ExTwtQdFp8=r0Gw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Append can break run-time partition pruning  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: Parallel Append can break run-time partition pruning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, 23 Apr 2020 at 02:37, Amit Langote <amitlangote09@gmail.com> wrote:
> One thing I remain concerned about is that it appears like we are no
> longer leaving the choice between parallel and non-parallel Append to
> the cost machinery which is currently the case.  AFAICS with patched,
> as long as parallel Append is enabled and allowed, it will be chosen
> over a non-parallel Append as the partial path.

Given the same set of paths, when would a non-parallel append be
cheaper than a parallel one? I don't see anything in cost_append()
that could cause the costs to come out higher for the parallel
version. However, I might have misunderstood something. Can you give
an example of a case that you think might change?

The cost comparison is still there for the cheapest parallel safe
normal path vs the cheapest partial path, so, when each of those paths
are allowed, then we will still end up with the cheapest paths for
each child.

> Regarding the patch, I had been assuming that the "pa" in
> pa_subpaths_valid stands for "parallel append", so it using the
> variable as is in the new code structure would be misleading.  Maybe,
> parallel_subpaths_valid?

Yeah, I had wondered if it would be better to rename it, I'd just not
thought too hard on what to call it yet.

David



pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: [PATCH] FIx explicit null dereference pointer (nbtree.c)
Next
From: Tomas Vondra
Date:
Subject: Re: sqlsmith crash incremental sort