Re: pg_autovacuum next steps

From: Joe Conway <mail(at)joeconway(dot)com>
To: "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_autovacuum next steps
Date: 2004-03-23 01:03:05
Message-ID: 405F8CC9.3010303@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Matthew T. O'Connor wrote:
> Joe Conway wrote:
>> This would be *really* nice to have. In my recent case, if
>> pg_autovacuum could work for say 3 minutes, and then back off for 2
>> minutes or so while the batch transactions hit, it would be ideal.
>>
> I'm not sure what you are suggesting here. As it stands right now,
> pg_autovacuum just issues a standard vacuum command, so there isn't
> anything pg_autovacuum can do until that command completes. There has
> been a lot of work going on trying to reduce performance impact
> associated with a vacuum (vacuum delay, ARC etc), hopefully that will
> make a big difference.

Hopefully it will. I've not had a chance yet to test against cvs tip.

I guess what I was suggesting would have to be built in to the lazy
vacuum process itself, similar to the vacuum delay stuff. I have no idea
if it would be practical, but ideally every X number of pages there
would be a way to detect "current load on the postgres cluster" or
"current load on the server", and then either sleep, or go full bore,
depending on the result and some threshold setting. Kind of like the
vacuum delay patch, but with "don't bother to sleep if the system is idle".

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-03-23 02:34:03 Re: float8 regression test failure in head
Previous Message Joe Conway 2004-03-23 00:49:34 Re: pg_autovacuum next steps