Re: Queuing all tables for analyze after recovery

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

In response to

Browse pgsql-hackers by date

  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