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

From David Rowley
Subject Re: pgsql: Support partition pruning at execution time
Date
Msg-id CAKJS1f_EdwgVAnBWM8Yw2wAmk6X-xS71KaJ2yShyOQ3fbLYzVw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Support partition pruning at execution time  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-committers
On 8 April 2018 at 11:26, David Rowley <david.rowley@2ndquadrant.com> wrote:
> On 8 April 2018 at 10:59, David Rowley <david.rowley@2ndquadrant.com> wrote:
>> Sometimes I see:
>>
>>  relname | relallvisible
>> ---------+---------------
>>  tprt_1  |             0
>>  tprt_2  |             1
>>
>> Other times I see:
>>
>>  relname | relallvisible
>> ---------+---------------
>>  tprt_1  |             0
>>  tprt_2  |             0
>
> The minimum set of commands I can find to recreate this are:
>
> drop table if exists tprt;
> create table tprt (col1 int) partition by range (col1);
> create table tprt_1 partition of tprt for values from (1) to (5001);
> create index tprt1_idx on tprt_1 (col1);
> insert into tprt values (10), (20), (501), (502), (505), (1001), (4500);
> vacuum tprt; select relname,relallvisible from pg_Class where relname
> like 'tprt%' and relkind = 'r';
>
> I get relallvisible = 0 once in maybe 20 or so attempts.
>
> I didn't manage to get the same without a partitioned table.

Anyway, this does not seem related to this patch. So no point in the
build farm blaming it.  There might be some reasonable explanation for
this that I just can't think of now.

I've attached a patch which gets rid of the index only scans in the tests.

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

Attachment

pgsql-committers by date:

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