Re: why partition pruning doesn't work?

On Tue, Jun 12, 2018 at 12:54 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Testing with valgrind + RELCACHE_FORCE_RELEASE is sufficient to disprove
> that, cf current results from lousyjack (which match my own testing).
> The partkey *is* disappearing under us.
>
> While I've not looked into the exact reasons for that, my first guess
> is that the partitioned table is not held open because it's not one
> of the ones to be scanned. Are you prepared to change something like
> that at this stage of the release cycle?

The partition key is immutable, so it should NOT be able to disappear
out from under us. Once you have defined the partitioning strategy
for a table and the partitioning keys associated with it, you can't
ever change it. The only reason we need keep_partkey at all, as
opposed to just assume that the relevant portion of the relcache entry
can't change at all, is because during relation creation we are
briefly in a state where the pg_class row exists and the
pg_partitioned_table row hasn't been set up yet. So I think your
guess that the relation is not kept open is likely to be correct.

As for whether to change it at this point in the release cycle, I
guess that, to me, depends on how invasive the fix is.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company