Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Robert Treat <xzilla@users.sourceforge.net>,
	Clarence Gardner <clarence@silcom.com>
Subject: Re: slow query
Date: Mon, 24 Feb 2003 10:45:20 -0800
User-Agent: KMail/1.4.3
Cc: Oleg Lebedev <oleg.lebedev@waterford.org>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
References: 
 <Pine.LNX.4.44.0302240925360.25665-100000@liberty.sba2.netlojix.net>
	<1046111434.1014.165.camel@camel>
In-Reply-To: <1046111434.1014.165.camel@camel>
MIME-Version: 1.0
Message-Id: <200302241045.20856.josh@agliodbs.com>
Content-Transfer-Encoding: quoted-printable

Robert,

> Actually if you are vacuuming frequently enough, it can (and should*)
> obviate a vacuum full. Be aware that frequently enough might mean really
> frequent, for instance I have several tables in my database that update
> every row within a 15 minute timeframe, so I run a "lazy" vacuum on
> these tables every 10 minutes. This allows postgresql to reuse the space
> for these tables almost continuously so I never have to vacuum full
> them.

This would assume absolutely perfect FSM settings, and that the DB never ge=
ts=20
thrown off by unexpected loads.  I have never been so fortunate as to work=
=20
with such a database.   However, I agree that good FSM tuning and frequent=
=20
regular VACUUMs can greatly extend the period required for running FULL.

I have not found, though, that this does anything to prevent the need for=
=20
REINDEX on frequently-updated tables.  How about you, Robert?

--=20
Josh Berkus
Aglio Database Solutions
San Francisco