Re: [HACKERS] Queuing all tables for analyze after recovery - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Queuing all tables for analyze after recovery
Date
Msg-id 31781.1508448417@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Queuing all tables for analyze after recovery  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Responses Re: [HACKERS] Queuing all tables for analyze after recovery
List pgsql-hackers
Vik Fearing <vik.fearing@2ndquadrant.com> writes:
> On 10/19/2017 10:54 PM, Tom Lane wrote:
>> Uh ... recommended by whom?  pg_statistic has exactly the same reliability
>> guarantees as the rest of the system catalogs.

> For data statistics, sure.  One thing I'm unhappy about is that
> pg_stat_all_tables is blank.

Well, that's because we throw away the stats collector's stats after a
crash -- or, in the failover case, because the promoted slave has its own
counters and not the master's.  ANALYZE isn't going to help that at all.

The fact that we drop those stats in a crash cycle is probably mostly
an overabundance of caution.  We could likely quit doing that, maybe
with a bit more validation effort when reading the files.

Not sure whether we ought to change anything about the failover case.
It's certainly reasonable for a standby server to have its own stats.

The one case where it might make sense to explicitly discard the counters
is when we do PITR to a previous system state.  That's not too common
though ...
        regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Tomasz Ostrowski
Date:
Subject: Re: [HACKERS] Queuing all tables for analyze after recovery
Next
From: Vik Fearing
Date:
Subject: Re: [HACKERS] Queuing all tables for analyze after recovery