Re: pg_autovacuum next steps

Поиск
Список
Период
Сортировка
От Matthew T. O'Connor
Тема Re: pg_autovacuum next steps
Дата
Msg-id 405F5FC1.7060700@zeut.net
обсуждение исходный текст
Ответ на Re: pg_autovacuum next steps  ("Alex J. Avriette" <alex@posixnap.net>)
Ответы Re: pg_autovacuum next steps  (Joe Conway <mail@joeconway.com>)
Re: pg_autovacuum next steps  ("Alex J. Avriette" <alex@posixnap.net>)
Список pgsql-hackers
Alex J. Avriette wrote:

>Hi, Matthew. For our uses, we found that pg_autovacuum did not behave
>as expected with vacuum_threshold set to 0.  For our purposes, we have
>a very good idea of how many tuples need to be slurped up over a given
>interval, and would like the autovacuum daemon to simply go through and
>vacuum when it hits a, er, threshold.
>  
>

Could you please explain this better, I don't really understand what the 
problem is.  If you want pg_autovacuum to perform a vacuum on a table 
that has had exactly X updates no matter what, you can just run it with 
-V0 -vX (where X is the vacuum threshold)  same thing can be done for 
analyze.  Are you saying that you did this and it did not work as expected?

>Having this in the postmaster would be fine by me (and in fact, I would
>even suggest that it belongs there), but I really need to have more
>flexibility or we are going to (read: I will be tasked with) be writing
>our own.
>  
>

Everyone agrees it should be in the backend eventually the questions 
were just if it was ready, and how or if it should change when it goes in.

>Sorry for the terseness -- and I haven't had a chance to go over the
>whole thread; we're moving from 7.3.2 to 7.4.2 on "the big database" 
>this week.
>

No problem, but I need more information to diagnose your problem.


Matthew



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Thoughts about updateable views
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_autovacuum next steps