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

From Andrew Gierth
Subject Re: pgsql: Support partition pruning at execution time
Date
Msg-id 876052idlu.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: pgsql: Support partition pruning at execution time  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: pgsql: Support partition pruning at execution time  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-committers
>>>>> "David" == David Rowley <david.rowley@2ndquadrant.com> writes:

 >> Setting autovacuum_naptime to 10 seconds makes it occur in 10 second
 >> intervals...

 David> Ok, I thought it might have been some concurrent vacuum on the
 David> table but the only tables I see being vacuumed are system
 David> tables.

It's not vacuum that tends to be the problem, but analyze (on any
table). Lazy-vacuum's snapshots are mostly ignored for computing global
xmin horizons by other vacuums, but analyze's snapshots are not.

 David> I tried performing a manual vacuum of each of these and could
 David> not get it to trigger, but then I did:

 David> select * from pg_class;

 David> from another session and then the script starts spitting out
 David> some errors.

Obviously, because the select holds a snapshot and therefore also holds
back OldestXmin.

You can't ever assume that data you just inserted will become
all-visible just because you just vacuumed the table, unless you know
that there is NO concurrent activity that might have a snapshot (and no
other possible reason why OldestXmin might be older than your insert).

-- 
Andrew (irc:RhodiumToad)


pgsql-committers by date:

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