Re: why partition pruning doesn't work?

On 12 June 2018 at 10:24, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> After looking closer, that code isn't just inefficient, it's flat
> out broken. The reason is that ExecSetupPartitionPruneState thinks
> it can store some pointers into the target relation's relcache entry
> in the PartitionPruneContext, and then continue to use those pointers
> after closing the relcache entry. Nope, you can't do that.

I think the best fix is to just have a separate FmgrInfo for each step
and partkey comparison. Some FmgrInfos will end up identical, but
that's probably a small price to pay. Perhaps they should be separate
anyway so that the fn_extra is not shared between different quals
comparing to the same partition key?

I went with an array of FmgrInfos rather than an array of pointers to
FmgrInfos for cache efficiency. This does require that InvalidOid is
0, since I've palloc0'd that memory, and I'm checking if the cache is
yet to be populated with: if
(!OidIsValid(context->stepcmpfuncs[stateidx].fn_oid))

Patch attached.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services