Re: pgsql: Support partition pruning at execution time

On 8 April 2018 at 11:26, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 8 April 2018 at 10:59, David Rowley <david(dot)rowley(at)2ndquadrant(dot)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