On 12 June 2018 at 02:26, Tom Lane <t...@sss.pgh.pa.us> wrote: >> However, if you didn't mean removing the executor >> initialise pruning, and just not remapping the arrays, then I'm not >> sure how we'd do that. I'd previously tried having NULL subnodes in >> the Append and I thought it required too much hacking work in >> explain.c, so I decided to just collapse the array instead and do what >> was required to make it work after having removed the unneeded >> subplans. Did you have another idea on how to do this? > > No, that was pretty much exactly what I was envisioning. I have > not looked at the consequences for explain.c but it seemed like > it couldn't be all that bad; and to my mind the remapping business > in the partition code is pretty bad. "It's all in one file" is not > a suitable justification for unintelligible, overcomplex code.
By all means, please have a look then. I've been down that route. I didn't like it. I particularly think the memory fragmentation is very good grounds for a good cache hit ratio either, not to mention the slowdown of bms_next_member when there are large gaps in the set. Keep in mind that we may scan the Append many times over when it's on the inside of a nested loop join. What you're proposing exchanges logic that fits neatly into one function for special logic that will be scattered all over explain.c. I really don't think that's the better of the two evils. I'd rather just see my last patch applied which simplifies the re-map code by removing the 2nd loop. Actually, even updating the present_parts to remove the unneeded subpartitioned table indexes is optional. We' just need to give up on the elog(ERROR, "partition missing from subplans"); error and assume that case is fine. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services