Re: statistics for shared catalogs not updated when autovacuum is off

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: statistics for shared catalogs not updated when autovacuum is off
Дата
Msg-id 56B0044C.1030001@gmx.net
обсуждение исходный текст
Ответ на Re: statistics for shared catalogs not updated when autovacuum is off  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: statistics for shared catalogs not updated when autovacuum is off  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 2/1/16 9:49 AM, Jim Nasby wrote:
> On 1/30/16 5:05 PM, Peter Eisentraut wrote:
>> When autovacuum is off, the statistics in pg_stat_sys_tables for shared
>> catalogs (e.g., pg_authid, pg_database) never update.  So seq_scan
>> doesn't update when you read the table, last_analyze doesn't update when
>> you run analyze, etc.
>>
>> But when you shut down the server and restart it with autovacuum on, the
> 
> What about with autovacuum still off?

nothing

>> updated statistics magically appear right away.  So seq_scan is updated
>> with the number of reads you did before the shutdown, last_analyze
>> updates with the time of the analyze you did before the shutdown, etc.
>> So the data is saved, just not propagated to the view properly.
>>
>> I can reproduce this back to 9.3, but not 9.2.  Any ideas?
> 
> ISTR that there's some code in the autovac launcher that ensures certain
> stats have been loaded from the file into memory; I'm guessing that the
> functions implementing the shared catalog views need something similar.

That's probably right.  Even with autovacuum on, the statistics for
shared catalogs do not appear as updated right away.  That is, if you
run VACUUM and then look at pg_stat_sys_tables right away, you will see
the stats for shared catalogs to be slightly out of date until the
minutely autovacuum check causes them to update.

So the problem exists in general, but the autovacuum launcher papers
over it every minute.




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jim Nasby
Дата:
Сообщение: Re: Freeze avoidance of very large table.
Следующее
От: Jim Nasby
Дата:
Сообщение: Re: Raising the checkpoint_timeout limit