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
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 |