Re: Second attempt, roll your own autovacuum

Поиск
Список
Период
Сортировка
От Glen Parker
Тема Re: Second attempt, roll your own autovacuum
Дата
Msg-id 45884263.2060103@nwlink.com
обсуждение исходный текст
Ответ на Re: Second attempt, roll your own autovacuum  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Second attempt, roll your own autovacuum  (Matthew O'Connor <matthew@zeut.net>)
Список pgsql-general
Tom Lane wrote:
> Glen Parker <glenebob@nwlink.com> writes:
>> I am still trying to roll my own auto vacuum thingy.
>
> Um, is this purely for hack value?

Don't be silly ;-)
Honestly I sort of thought the problem was fairly obvious.

> What is it that you find inadequate
> about regular autovacuum?  It is configurable through the pg_autovacuum
> catalog --- which I'd be the first to agree is a sucky user interface,
> but we're not going to set the user interface in concrete until we are
> pretty confident it's feature-complete.  So: what do you see missing?

Traditional vacuum does every table in the DB, which is absolutely The
Wrong Thing for us.  Vacuum can be fired against individual tables, but
then how do I know which tables need it?  Autovacuum is smart about
which tables it hits, but exceedingly stupid about *when* it hits them.

What I want is a way to do all needed vacuuming, in as short a time span
as possible, when I decide it should be done.  For us, that's between ~2
AM and ~3 AM each morning.  If a vacuum runs past 3 AM, so be it, but
it's better to hit it hard and try to be done by 3 AM than it is to
lolly gag around about it unil 5 AM.

The obvious answer for me is to vacuum all the tables that autovacuum
would hit, but only on demand.  Something like "VACUUM CONDITIONAL WHERE
autovacuum_says_so()" :-)

-Glen


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

Предыдущее
От: Vivek Khera
Дата:
Сообщение: Re: FreeBSD 6.0 PostgreSQL upgrade
Следующее
От: Chris Browne
Дата:
Сообщение: Re: Autovacuum Improvements