On 2 August 2018 at 11:48, Tom Lane <t...@sss.pgh.pa.us> wrote: > I've pushed the v3 patch with a lot of editorial work (e.g. cleaning > up comments you hadn't).
Thanks for doing that. > >> In [1] I mentioned that I think that bug should be fixed as part of >> this bug fix too. > > I didn't include this change because (a) it's late, (b) no test > case was included, and (c) I don't entirely believe it anyway. > How would a rel be both leaf and nonleaf? Isn't this indicative > of a problem somewhere upstream in the planner? It's probably best discussed on the other thread, but it seems to be by design in accumulate_append_subpath(). Parallel Append nodes don't get flattened if they contain a mix of parallel aware and non-parallel aware subplans. So you might be right, maybe a better option is to have that code reorder the subplans so that the parallel aware ones stay at the end. I'm just not convinced that fixing that code means it would mean it would never happen again. It does not seem too outrageous to me to support nested Appends, and with those, what else would the Path's parent RelOptInfo be if it's not the partitioned table that the node's subpaths belong to? Or maybe, in that case, the partitioned_rels belonging to the sub-Append should not have been included in the List for the top-level Append. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
