Re: pgsql: Support partition pruning at execution time

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

From: David Rowley <david.rowley@2ndquadrant.com>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-committers@lists.postgresql.org
Date: 2018-04-08T02:56:21Z
Lists: pgsql-hackers
On 8 April 2018 at 12:15, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> Yeah, I don't quite understand this problem, and I tend to agree that
> it likely isn't this patch's fault.  However, for the moment I'm going
> to avoid pushing the patch you propose because maybe there's a bug
> elsewhere and it'd be good to understand it.  I'm looking at it now.
>
> If others would prefer me to push David's patch (or do so themselves),
> I'm not dead set against that.

I just wanted to share this:

#!/bin/bash
for i in {1..1000000}
do
        if [ $(psql --no-psqlrc -w -v ON_ERROR_STOP=0 -d postgres -q
-A -F " " -t  <<EOF
                        drop table if exists tprt;
                        create table tprt (col1 int);
                        create index tprt_idx on tprt (col1);
                        insert into tprt values (10), (20), (501),
(502), (505), (1001), (4500);
                        vacuum tprt;
                        select relallvisible from pg_Class where
relname like 'tprt%' and relkind = 'r';
EOF
) = "0" ];
        then
                echo "[$(date --iso-8601=seconds)]: 0"
        fi

done

If I run this I only get the wrong result from the visibility map in
60 second intervals:

Check this output:

[2018-04-08T02:50:34+0000]: 0
[2018-04-08T02:50:34+0000]: 0
[2018-04-08T02:50:34+0000]: 0
[2018-04-08T02:50:34+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:50:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:51:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0
[2018-04-08T02:52:35+0000]: 0

It happens 12 or 13 times on my machine, then does not happen again
for 60 seconds, then happens again.

-- 
 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