Re: Size for vacuum_mem

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: Size for vacuum_mem
Дата
Msg-id 1039125476.11130.179.camel@camel
обсуждение исходный текст
Ответ на Re: Size for vacuum_mem  ("Francisco Reyes" <lists@natserv.com>)
Ответы Re: Size for vacuum_mem  ("David Blood" <david@matraex.com>)
Список pgsql-general
On Thu, 2002-12-05 at 12:57, Francisco Reyes wrote:
> > For these, you can try just using a plain VACUUM and seeing how
> > effective that is at reclaiming space.
>
> I am not too concerned with space reclamation. In theory if I don't do
> vacuum fulls I may have some dead space, but it would get re-used daily.
> My concern is the performance hit I would suffer with the table scans.
>

you should see very little performance impact from lazy vacuuming. If
there is a performance hit, you can gain some offset by quicker queries
(if you do vacuum analyze).  And remember, lazy vacuums are non-blocking
so users won't see an impact from that standpoint. The trick is to find
a good interval that will keep your tables from growing too big. I have
one table that updates every 10 minutes (the whole content of the table
gets updated within 15 minutes), which keeps the size very manageable
(it's not a huge table, or I would do it more).  In this scenario, you
can still do vacuum fulls if you feel the need, but they should take
much less time.

Robert Treat



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query breaking with unknown expression type (lost s
Следующее
От: "Al Bean"
Дата:
Сообщение: the "/usr/local/pgsql/data" directory size