Re: pgsql: Support partition pruning at execution time
От | Andrew Gierth |
---|---|
Тема | Re: pgsql: Support partition pruning at execution time |
Дата | |
Msg-id | 876052idlu.fsf@news-spur.riddles.org.uk обсуждение исходный текст |
Ответ на | Re: pgsql: Support partition pruning at execution time (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: pgsql: Support partition pruning at execution time
|
Список | 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 по дате отправления: