Re: pgsql: Support partition pruning at execution time

David Rowley <david.rowley@2ndquadrant.com>

From: David Rowley <david.rowley@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-committers@lists.postgresql.org
Date: 2018-04-07T23:38:23Z
Lists: pgsql-hackers

Attachments

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

Commits

  1. Update Append's idea of first_partial_plan

  2. Fix IndexOnlyScan counter for heap fetches in parallel mode

  3. Fix incorrect logic for choosing the next Parallel Append subplan

  4. Minor comment updates

  5. Attempt to stabilize partition_prune test output.

  6. Support partition pruning at execution time