Re: pgsql: Support partition pruning at execution time

Andrew Gierth <andrew@tao11.riddles.org.uk>

From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: David Rowley <david.rowley@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-committers@lists.postgresql.org
Date: 2018-04-08T03:34:22Z
Lists: pgsql-hackers
>>>>> "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)


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