Re: pg_autovacuum next steps
От | Joe Conway |
---|---|
Тема | Re: pg_autovacuum next steps |
Дата | |
Msg-id | 405F8CC9.3010303@joeconway.com обсуждение исходный текст |
Ответ на | Re: pg_autovacuum next steps ("Matthew T. O'Connor" <matthew@zeut.net>) |
Список | 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 по дате отправления: