Horton

Re: why partition pruning doesn't work?

Jeff Janes <jeff.janes@gmail.com>

View thread View on postgr.es
From: Jeff Janes <jeff.janes@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Dmitry Dolgov <9erthalion6@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-06-02T21:16:51Z
Lists: pgsql-hackers 
On Fri, Jun 1, 2018 at 11:53 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>
> I agree though that it seems strange to special-case SQLValueFunction
> rather than any-stable-expression.  As long as the evaluation happens
> at executor start (i.e. with the query's run-time snapshot) it should
> be reasonable to simplify any stable expression.
>
> It's worth questioning whether this is a bug fix or an improvement.
> If the latter, it probably ought to wait for v12.
>

If explaining the change requires reference to tokens from the source code,
rather than something an end user could understand, I'd argue it is a bug
fix rather than an improvement.

Cheers,

Jeff

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