Received: from maia.hub.org (maia-3.hub.org [200.46.204.243])
	by mail.postgresql.org (Postfix) with ESMTP id C8D3B633041
	for <pgsql-sql-postgresql.org@mail.postgresql.org>;
	Thu, 27 May 2010 11:03:37 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia,
	port 10024) with ESMTP id 27853-08 for
	<pgsql-sql-postgresql.org@mail.postgresql.org>;
	Thu, 27 May 2010 14:03:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 91AE4632F14
	for <pgsql-sql@postgresql.org>; Thu, 27 May 2010 11:03:30 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o4RE3SNh014436;
	Thu, 27 May 2010 10:03:28 -0400 (EDT)
To: "Good, Thomas" <tgood@svcmcny.org>
cc: "pgsql-sql@postgresql.org" <pgsql-sql@postgresql.org>
Subject: Re: Question about slow queries... 
In-reply-to: 
 <FA041D403EDFCD4397E1F6382360ECFCC2979966F3@SVCMCEMAIL.svcmc.svcmcny.org>
References: 
 <FA041D403EDFCD4397E1F6382360ECFCC2979966F3@SVCMCEMAIL.svcmc.svcmcny.org>
Comments: In-reply-to "Good, Thomas" <tgood@svcmcny.org>
	message dated "Fri, 21 May 2010 11:44:29 -0400"
Date: Thu, 27 May 2010 10:03:28 -0400
Message-ID: <14435.1274969008@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9,
	T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201005/129
X-Sequence-Number: 34177

"Good, Thomas" <tgood@svcmcny.org> writes:
> I have a question about a query that starts out fine and over time slows to a halt - but only on a webhosted site.  Locally it does fine.

> The query is a singleton select (no joins), hitting a table with about
> 5,000 records in it. Over time the query slows to a crawl and I have to
> dump and rebuild/repopulate to restore efficiency. Vacuum does nothing
> but a dump and reload fixes the problem and the query runs lightning
> fast again -- for a period of a week or so.

If a dump and reload fixes it then you have table-bloat or index-bloat
problems.  A simple VACUUM won't fix that once it's happened.  You need
to VACUUM more often so that it doesn't get bloated in the first place.

> Locally I'm running 8.4.2, the webhost is 8.1.18

... and the reason for the difference is probably that 8.4.x has a
reasonably decent autovacuum facility, which 8.1.x does not.  Suggest
bugging your webhost provider to provide a less obsolete version of
Postgres.

			regards, tom lane