"Luke Lonergan" <LLonergan@xxxxxxxxxxxxx> writes: > The approach we took was to recognize the ordering of child nodes and > propagate that to the append in the special case of only one child (after > CE). This is the most common use-case in 'partitioning', and so is an easy, > high payoff low amount of code fix. Ah yes, we should definitely try to prune singleton append nodes. On a lark I had tried to do precisely that to see what would happen but ran into precisely the problem you had to solve here with your pullup_vars function. That's one of the functions which wasn't included in the original patch so I'll look at the patch from the queue to see what's involved. Actually currently it's not a common case because we can't eliminate the parent partition. I have some ideas for how to deal with that but haven't written them up yet. In theory if we can preserve ordering across append nodes there's no good reason to prune them. But generally I think simplifying the plan is good if only to present simpler plans to the user. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
