Re: [HACKERS] Queuing all tables for analyze after recovery

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Queuing all tables for analyze after recovery
Дата
Msg-id 31781.1508448417@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Queuing all tables for analyze after recovery  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Ответы Re: [HACKERS] Queuing all tables for analyze after recovery  (Vik Fearing <vik.fearing@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Tomasz Ostrowski
Дата:
Сообщение: Re: [HACKERS] Queuing all tables for analyze after recovery
Следующее
От: Vik Fearing
Дата:
Сообщение: Re: [HACKERS] Queuing all tables for analyze after recovery