Re: Size for vacuum_mem

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Francisco Reyes <lists(at)natserv(dot)com>
Cc: "neilc(at)samurai(dot)com" <neilc(at)samurai(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Size for vacuum_mem
Date: 2002-12-05 21:57:56
Message-ID: 1039125476.11130.179.camel@camel
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Al Bean 2002-12-05 22:02:53 the "/usr/local/pgsql/data" directory size
Previous Message Tom Lane 2002-12-05 21:51:06 Re: Query breaking with unknown expression type (lost s