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 CAKJS1f9jyTWmTcyqpSaFs5XmHqvbS7QXtmvvJyC13nXJbSV_Sw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Support partition pruning at execution time  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: pgsql: Support partition pruning at execution time  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-committers
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


pgsql-committers by date:

Previous
From: Andres Freund
Date:
Subject: pgsql: Remove overzeleous assertions in pg_atomic_flag code.
Next
From: David Rowley
Date:
Subject: Re: pgsql: Support partition pruning at execution time