Re: why partition pruning doesn't work?

On 12 June 2018 at 02:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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