On Thu, Aug 2, 2018 at 8:42 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> Wouldn't that code have more flexibility to flatten the Append if it
> were to, instead of looking at the Append's subpaths, look at the
> subpath's Parent RelOptInfo paths and just use the Append and
> MergeAppend as a container to identify the relations that must be
> included, rather than the paths that should be?
Well, we actually start with a list of RelOptInfos, take the cheapest
path from each whether partial or non-partial, and then build a
Parallel Append out of the result, so there's no need to work backward
from the chosen path to the Parallel Append. As to whether it's ever
better to take a path other than the cheapest to facilitate
flattening, I'm not sure. At the moment, I can't think of a scenario
in which that would pay off, but there may be one. I think that if
we're using Parallel Append at all, we're likely going to use it
throughout the plan tree, in which case everything will get flattened
just fine. There might well be corner cases where that isn't so,
though, and in some of those flattening may be advantageous, but I
can't think of anything really clear and obvious. You might have
better ideas than I do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
