From: | Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)pl> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Queuing all tables for analyze after recovery |
Date: | 2017-10-19 20:42:04 |
Message-ID: | 91ffc39e-f8c7-87e2-077c-601d4ba678e7@ato.waw.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi.
Some (maybe all) row statistics are lost after the database has
recovered after a failover. So it's recommended to ANALYZE all databases
in a cluster after recovery.
Amazon's AWS RDS (their managed SQL databases service) even sends an
email "consider running analyze if your database is slow" after a
failover of so called MultiAZ databases (with fast automatic failover
for double price). Funny that they send it for both PostgreSQL and
Oracle databases, which, I suppose, confuses Oracle DBA's greatly.
And in AWS RDS MultiAZ a failover is pretty common. Minor version
upgrade - failover. A storage hiccup - failover. Out of memory - failover.
Shouldn't this analyze be queued and all tables analyzed automatically
after failover by autovacuum daemon? With up to autovacuum_max_workers
in parallel?
It might save some DBA's from a couple of lost sleeping hours for sure.
What do you think? A GUC option? On by dafault? Maybe even backported,
but off by default in released versions?
--
Tomasz "Tometzky" Ostrowski
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2017-10-19 20:44:01 | Re: [COMMITTERS] pgsql: Fix traversal of half-frozen update chains |
Previous Message | Tomasz Ostrowski | 2017-10-19 20:39:59 | Queuing all tables for analyze after recovery |