David Rowley <david.row...@2ndquadrant.com> writes: > It seems like a good idea for the planner not to generate Append or > MergeAppend paths when the node contains just a single subpath. > ... > Perhaps there is also a "Method 3" which I've not thought about which > would be much cleaner.
Have you considered turning AppendPath with a single child into more of a special case? I think this is morally equivalent to your ProxyPath proposal, but it would take less new boilerplate code to support. If you taught create_append_path to inherit the child's pathkeys when there's only one child, and taught createplan.c to skip making the useless Append node, I think you might be nearly done. This might seem a bit ugly, but considering that zero-child AppendPaths are already a special case (and a much bigger one), I don't have much of a problem with decreeing that one-child is also a special case. As an example of why this might be better than a separate ProxyPath node type, consider this call in add_paths_to_append_rel: /* * If we found unparameterized paths for all children, build an unordered, * unparameterized Append path for the rel. (Note: this is correct even * if we have zero or one live subpath due to constraint exclusion.) */ if (subpaths_valid) add_path(rel, (Path *) create_append_path(rel, subpaths, NULL, 0, partitioned_rels)); That comment could stand a bit of adjustment with this approach, but the code itself requires no extra work. Now, you would have to do something about this in create_append_plan: /* * XXX ideally, if there's just one child, we'd not bother to generate an * Append node but just return the single child. At the moment this does * not work because the varno of the child scan plan won't match the * parent-rel Vars it'll be asked to emit. */ but that's going to come out in the wash someplace, no matter what you do. Leaving it for the last minute is likely to reduce the number of places you have to teach about this. regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers