On Thu, Aug 2, 2018 at 8:42 PM, David Rowley <david.row...@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
