Re: Autovacuum launcher doesn't notice death of postmaster immediately

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Autovacuum launcher doesn't notice death of postmaster immediately
Дата
Msg-id 20070608214427.GS92628@nasby.net
обсуждение исходный текст
Ответ на Re: Autovacuum launcher doesn't notice death of postmaster immediately  (Matthew O'Connor <matthew@zeut.net>)
Ответы Re: Autovacuum launcher doesn't notice death of postmaster immediately  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Fri, Jun 08, 2007 at 09:49:56AM -0400, Matthew O'Connor wrote:
> Michael Paesold wrote:
> >Matthew T. O'Connor schrieb:
> >>Do we need a configurable autovacuum naptime at all?  I know I put it
> >>in the original contrib autovacuum because I had no idea what knobs
> >>might be needed.  I can't see a good reason to ever have a naptime
> >>longer than the default 60 seconds, but I suppose one might want a
> >>smaller naptime for a very active system?
> >
> >A PostgreSQL database on my laptop for testing. It should use as little
> >resources as possible while being idle. That would be a scenario for
> >naptime greater than 60 seconds, wouldn't it?
>
> Perhaps, but that isn't the use case PostgresSQL is being designed for.
>  If that is what you really need, then you should probably disable
> autovacuum.  Also a very long naptime means that autovacuum will still
> wake up at random times and to do the work.  At least with short
> naptime, it will do the work shortly after you updated your tables.

Agreed. Maybe 10 minutes might make sense, but the overhead of checking
to see if anything needs vacuuming is pretty tiny.

There *is* reason to allow setting the naptime smaller, though (or at
least there was; perhaps Alvero's recent changes negate this need):
clusters that have a large number of databases. I've worked with folks
who are in a hosted environment and give each customer their own
database; it's not hard to get a couple hundred databases that way.
Setting the naptime higher than a second in such an environment would
mean it could be hours before a database is checked for vacuuming.
--
Jim Nasby                                      decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Binary mode copy in from stdin
Следующее
От: "Jim C. Nasby"
Дата:
Сообщение: Re: Autovacuum launcher doesn't notice death of postmaster immediately