Re: Autovacuum and Autoanalyze - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Autovacuum and Autoanalyze
Date
Msg-id 603c8f070809160732kaffacb5o223d45e7f615512b@mail.gmail.com
Whole thread Raw
In response to Autovacuum and Autoanalyze  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Autovacuum and Autoanalyze  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> Disabling autovacuum can have catastrophic effects, since it disables
> the ANALYZing of tables.
>
> Can we have a mode where we disable autoVACUUM yet enable autoANALYZE?
>
> ANALYZE times are fairly bounded because of the way we do sampling.
> VACUUM times are not bounded at all, and typically > O(n). So it makes
> sense to switch off the VACUUM at certain times, but never good to
> switch off ANALYZE.

This seems reasonable.

> While we're there, it would be useful if CREATE TABLE AS SELECT was
> followed by an automatic ANALYZE. Especially important for temp tables.

This seems like the wrong solution.  There is a general problem that
bulk data loads on an empty table tend to result in horrible query
plans, but not all of those will be created using CREATE TABLE AS
SELECT.  Someone may easily do a COPY or just a bunch of INSERTs.
Maybe something like: If the table has never been ANALYZEd, force an
immediate ANALYZE before planning the first SELECT, UPDATE, or DELETE.

And maybe also do the same thing if the table has grown significantly
(not sure what the threshold should be) since the last ANALYZE.

I'm not sure exactly what is practical here but it would certainly be
nice to have some solution.  This has got to be my #1 cause of
extremely slow queries.

...Robert


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: per-table autovacuum configuration
Next
From: Simon Riggs
Date:
Subject: Re: Subtransaction commits and Hot Standby