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:25:58Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jun 11, 2018 at 6:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Not sure about a good fix for this.  It seems annoying to copy the
>> rel's whole partkey data structure into query-local storage, but
>> I'm not sure we have any choice.  On the bright side, there might
>> be an opportunity to get rid of repeated runtime fmgr_info lookups
>> in cross-type comparison situations.

> Is this the same issue I raised in
> https://www.postgresql.org/message-id/flat/CA%2BTgmoYKToP4-adCFFRNrO21OGuH%3Dphx-fiB1dYoqksNYX6YHQ%40mail.gmail.com
> or a similar issue that creeps up at execution time?

Well, it's related to that: *if* we held the relcache entry open for
the duration of the query, and *if* holding such a pin were sufficient
to guarantee the contents of the entry's partition data couldn't change
or even move, then we could avoid doing so much copying.  But as we
discussed then, neither condition is true, and I don't think either one is
cheap to make true.  Certainly there's no logic in the relcache to detect
changes of partition data like we do for, say, triggers.

			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