Re: statistics for shared catalogs not updated when autovacuum is off - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: statistics for shared catalogs not updated when autovacuum is off
Date
Msg-id 56B0044C.1030001@gmx.net
Whole thread Raw
In response to Re: statistics for shared catalogs not updated when autovacuum is off  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: statistics for shared catalogs not updated when autovacuum is off
List 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 by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Jim Nasby
Date:
Subject: Re: Raising the checkpoint_timeout limit