From: | Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Queuing all tables for analyze after recovery |
Date: | 2017-10-19 21:16:23 |
Message-ID: | e4e2c107-1400-3a7a-7da1-7a8da914c13f@ato.waw.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Actually I'm not exactly sure what is lost and what is preserved. I'm
pretty sure that pg_stat_all_tables and similar views turn out with no
data after a failover.
Also I have some experience with badly performing databases after a
failover, which went back to normal performance after whole cluster
analyze. This email from AWS suggests that it's not only me.
> I don't deny that there might be cases where this is worth doing, but
> it does not seem so likely that it should be part of one's standard
> checklist. Much less something that we should expend a great deal
> of effort to automate.
I assumed that the effort here shouldn't be that large. I imagined a
simple check if the statistics are missing when considering tables for
analyze by autovacuum. But I'm not a programmer, so I might misestimate
this effort badly.
--
Regards,
Tomasz "Tometzky" Ostrowski
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-10-19 21:26:57 | Re: Queuing all tables for analyze after recovery |
Previous Message | Vik Fearing | 2017-10-19 21:15:56 | Re: Queuing all tables for analyze after recovery |