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
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 |