On 9 August 2018 at 15:33, Tom Lane <t...@sss.pgh.pa.us> wrote: > Nonetheless, it's a damfool query plan, because we'll be going through > parallel worker startup/shutdown overhead 4 times for no benefit. > We really should put in some kind of logic to force those sibling > Gathers to be aggregated into one, or else disallow them altogether.
I started debugging this to see where things go wrong. I discovered that add_paths_to_append_rel() is called yet again from apply_scanjoin_target_to_paths() and this is where it's all going wrong. The problem is that the gather paths have been tagged onto the partial paths by this time, so accumulate_append_subpath() has no code to look through those to fetch the Append/MergeAppend subpaths, so it just appends the entire path to the subpaths List. This all worked before 96030f9a481. This commit moved where generate_gather_paths() is called. I'm having a hard time understanding why we need to call add_paths_to_append_rel() from apply_scanjoin_target_to_paths(). The name of the function does not seem to imply that we'd do this. The comment just explains "what" rather than "why" making it a bit useless. /* Build new paths for this relation by appending child paths. */ if (live_children != NIL) add_paths_to_append_rel(root, rel, live_children); I also think that accumulate_append_subpath() is a bit of a fragile way of flattening the append rel's paths, but I feel it's probably apply_scanjoin_target_to_paths() that's at fault here. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services