Re: pg_autovacuum next steps - Mailing list pgsql-hackers

From Joe Conway
Subject Re: pg_autovacuum next steps
Date
Msg-id 405F8CC9.3010303@joeconway.com
Whole thread Raw
In response to Re: pg_autovacuum next steps  ("Matthew T. O'Connor" <matthew@zeut.net>)
List 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



pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: pg_autovacuum next steps
Next
From: Josh Berkus
Date:
Subject: Re: [DEFAULT] Daily digest v1.4346 (20 messages)