Horton

Re: why partition pruning doesn't work?

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Dmitry Dolgov <9erthalion6@gmail.com>, Jeff Janes <jeff.janes@gmail.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-06-12T16:54:41Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> I think we DO hold relations open for the duration of execution
> (though not necessarily between planning and execution).  And there is
> code in RelationClearRelation to avoid changing rd_partkey and
> rd_partdesc if no logical change has occurred.

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?

			regards, tom lane

Commits

  1. Fix up run-time partition pruning's use of relcache's partition data.

  2. Fix access to just-closed relcache entry.

  3. Improve ExecFindInitialMatchingSubPlans's subplan renumbering logic.

  4. Improve commentary about run-time partition pruning data structures.

  5. Fix run-time partition pruning code to handle NULL values properly.

  6. Assorted cosmetic cleanup of run-time-partition-pruning code.

  7. Relocate partition pruning structs to a saner place.

  8. Improve run-time partition pruning to handle any stable expression.

  9. Support partition pruning at execution time