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: David Rowley <david.rowley@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.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-07-16T00:45:54Z
Lists: pgsql-hackers 
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 16 July 2018 at 12:12, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Jul 15, 2018 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> What we'd be better off doing, if we go this route, is to install an
>>> assertion-build-only test that verifies during relation_open(NoLock)
>>> that some kind of lock is already held on the rel.

> Wouldn't it be better to just store the Relation indexed by its relid
> somewhere the first time we opened it? Then just do a direct array
> lookup on that rather than looking up by hashtable in syscache?

That would require carrying said array clear through from the parser to
the executor, plus we'd have some fun keeping it in sync with the RTE
changes that happen in the rewriter and planner, plus it's not entirely
clear where we'd close those relations in cases where the generated
plan isn't fed to the executor immediately (or gets copied in any way).
I don't think it's worth going that far.

I *do* think it might be worth behaving like that within the executor
by itself, and said so upthread.  In that situation, we have a clear
place to do relation closes during ExecutorEnd, so it's not as messy
as a more general approach would be.

			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