Re: Autovacuum and Autoanalyze

From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Autovacuum and Autoanalyze
Date: 2008-09-16 14:32:34
Message-ID: 603c8f070809160732kaffacb5o223d45e7f615512b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2008-09-16 14:38:45 Re: Subtransaction commits and Hot Standby
Previous Message Alvaro Herrera 2008-09-16 14:24:31 Re: per-table autovacuum configuration