Re: Autovacuum and Autoanalyze

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Autovacuum and Autoanalyze
Дата
Msg-id 603c8f070809160732kaffacb5o223d45e7f615512b@mail.gmail.com
обсуждение исходный текст
Ответ на Autovacuum and Autoanalyze  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Autovacuum and Autoanalyze
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: per-table autovacuum configuration
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Subtransaction commits and Hot Standby