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
-
Update Append's idea of first_partial_plan
- b7e2cbc5b49f 11.0 landed
-
Fix IndexOnlyScan counter for heap fetches in parallel mode
- 15a8f8caad14 11.0 landed
-
Fix incorrect logic for choosing the next Parallel Append subplan
- 468abb8f7a69 11.0 landed
-
Minor comment updates
- d7a95f06a1a1 11.0 landed
-
Attempt to stabilize partition_prune test output.
- b47a86f5008f 11.0 landed
-
Support partition pruning at execution time
- 499be013de65 11.0 cited