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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: statistics for shared catalogs not updated when autovacuum is off
Date: 2016-02-02 01:20:12
Message-ID: 56B0044C.1030001@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-02-02 01:24:50 Re: Raising the checkpoint_timeout limit
Previous Message Jim Nasby 2016-02-02 01:15:14 Re: Freeze avoidance of very large table.