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  (David Rowley <david.rowley@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: pgsql: Support partition pruning at execution time
Следующее
От: David Rowley
Дата:
Сообщение: Re: pgsql: Support partition pruning at execution time