Re: Queuing all tables for analyze after recovery

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com>
Cc: Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)pl>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Queuing all tables for analyze after recovery
Date: 2017-10-19 21:26:57
Message-ID: 31781.1508448417@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2017-10-19 21:30:13 Re: Queuing all tables for analyze after recovery
Previous Message Tomasz Ostrowski 2017-10-19 21:16:23 Re: Queuing all tables for analyze after recovery