Re: why partition pruning doesn't work?

Andrew Dunstan <andrew.dunstan@2ndquadrant.com>

From: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, David Rowley <david.rowley@2ndquadrant.com>
Cc: 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-12T11:47:16Z
Lists: pgsql-hackers

On 06/11/2018 06:41 PM, Andrew Dunstan wrote:
>
>
> On 06/11/2018 06:24 PM, Tom Lane wrote:
>>
>> If we had any buildfarm critters running valgrind on
>> RELCACHE_FORCE_RELEASE or CLOBBER_CACHE_ALWAYS builds, they'd have
>> detected use of uninitialized memory here ... but I don't think we have
>> any.  (The combination of valgrind and CCA would probably be too slow to
>> be practical :-(, though maybe somebody with a fast machine could do
>> the other thing.)
>>
>>
>
>
> I don't have a fast machine, but I do have a slow machine already 
> running valgrind and not doing much else :-) Let's see how lousyjack 
> does with -DRELCACHE_FORCE_RELEASE
>
>


It added about 20% to the run time. That's tolerable, so I'll leave it on.

cheers

andrew

-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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