Re: pgsql: Support partition pruning at execution time - Mailing list pgsql-hackers

From David Rowley
Subject Re: pgsql: Support partition pruning at execution time
Date
Msg-id CAKJS1f8n4X_pECdmm1vebY-kvNu30bpC6jRis8dQWYEQcUh48w@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Support partition pruning at execution time  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 11 April 2018 at 03:42, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> 2. Do we want to revert Andrew's test stabilization patch?  If I
>> understand correctly, the problem is the inverse of what was diagnosed:
>> "any running transaction at the time of the test could prevent pages
>> from being set as all-visible".  That's correct, but the test doesn't
>> depend on pages being all-visible -- quite the contrary, it depends on
>> the pages NOT being all-visible (which is why the HeapFetches counts are
>> all non-zero).  Since the pages contain very few tuples, autovacuum
>> should never process the tables anyway.
>
> I did not especially like the original test output, because even without
> the bug at hand, it seemed to me the number of heap fetches might vary
> depending on BLCKSZ.  Given that the point of the test is just to check
> partition pruning, seems like IOS vs regular indexscan isn't a critical
> difference.  I'd keep Andrew's change but fix the comment.

hmm, I don't feel strongly about reverting or not, but if
[auto-]vacuum has not visited the table, then I don't see why BLCKSZ
would have an effect here.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: pgsql: Support partition pruning at execution time
Next
From: Robert Haas
Date:
Subject: Re: pgsql: Support partition pruning at execution time