Re: Autovacuum in the backend

From: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
To: Alvaro Herrera <alvherre(at)surnet(dot)cl>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autovacuum in the backend
Date: 2005-06-16 04:56:36
Message-ID: 42B10684.9080401@zeut.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Alvaro Herrera wrote:

>On Thu, Jun 16, 2005 at 02:09:47PM +1000, Neil Conway wrote:
>
>
>>Alvaro Herrera wrote:
>>
>>
>>>One issue I do have to deal with right now is how many autovacuum
>>>processes do we want to be running. The current approach is to have one
>>>autovacuum process. Two possible options would be to have one per
>>>database, and one per tablespace. What do people think?
>>>
>>>
>>Why do we need more than one pg_autovacuum process?
>>
>>
>
>The only reason I considered it is because you can use the regular
>catalog-management routines to handle the new pg_autovacuum system
>catalog. With a single process, we need to issue SQL queries. This is
>very ugly IMHO.
>
>

It was always my intention to have VACUUM and ANALYZE update the new
autovacuum system table, I just never got around to making that happen.

Personally I would vote for simplicty for now, that is only one
autovacuum process and allow it to only issue one VACUUM command at any
given time. Something more complicated sounds to me like a 2nd
generation optimisation.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Matthew T. O'Connor 2005-06-16 04:58:01 Re: Autovacuum in the backend
Previous Message Tom Lane 2005-06-16 04:55:05 Re: [HACKERS] INHERITS and planning

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthew T. O'Connor 2005-06-16 04:58:01 Re: Autovacuum in the backend
Previous Message Tom Lane 2005-06-16 04:55:05 Re: [HACKERS] INHERITS and planning