Date: Mon, 24 Sep 2007 11:29:07 -0400
From: Bill Moran <wmoran@collaborativefusion.com>
To: "=?ISO-8859-1?Q?\"G=E1bor_Farkas\"?=" <gabor@nekomancer.net>
Cc: Heikki Linnakangas <heikki@enterprisedb.com>,
	pgsql-performance@postgresql.org
Subject: Re: select count(*) performance (vacuum did not help)
Message-Id: <20070924112907.cbede7e6.wmoran@collaborativefusion.com>
In-Reply-To: <46F7D453.4050908@nekomancer.net>
References: <46F7C494.1050604@nekomancer.net>
	<46F7C9F1.1080805@enterprisedb.com>
	<46F7D207.3000901@nekomancer.net> <46F7D2C7.70105@enterprisedb.com>
	<46F7D453.4050908@nekomancer.net>
Organization: Collaborative Fusion
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

In response to "G=E1bor Farkas" <gabor@nekomancer.net>:

> Heikki Linnakangas wrote:
> > G=E1bor Farkas wrote:
> >>
> >> if i do a full vacuum to that table only, will the database still serve
> >> data from the other tables at a normal speed?
> >=20
> > Yes. The extra I/O load vacuum full generates while it's running might
> > disrupt other activity, though.
> >=20
>=20
> i see.
>=20
> will i achieve the same thing by simply dropping that table and=20
> re-creating it?

Yes.  Once you've done so, keep up the vacuum schedule you've already
established.  You may want to (as has already been suggested) explicitly
vacuum this table after large delete operations as well.

--=20
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023