To: Shawn <postgres@xmtservices.net>
cc: pgsql-performance@postgresql.org
Subject: Re: Slow Query 
In-reply-to: <20070903165334.0da769c1@boffin.xmtservices.net> 
References: <20070901102947.0c0a50a3@boffin.xmtservices.net>
	<46DA9522.EE98.0025.0@wicourts.gov>
	<20070903091558.0780b963@boffin.xmtservices.net>
	<46DC071D.EE98.0025.0@wicourts.gov>
	<20070903165334.0da769c1@boffin.xmtservices.net>
Comments: In-reply-to Shawn <postgres@xmtservices.net>
	message dated "Mon, 03 Sep 2007 16:53:34 -0700"
Date: Mon, 03 Sep 2007 20:49:42 -0400
Message-ID: <6184.1188866982@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Shawn <postgres@xmtservices.net> writes:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
>> Did you ever capture the output of VACUUM VERBOSE against this table

> vacuum verbose analyze shawns_data;
> ...
> INFO:  index "shawns_data_pkey" now contains 15445 row versions in
> 35230 pages

[ and comparably bloated sizes for other indexes ]

Ouch!  The table itself doesn't look nearly as bad:

> INFO:  "shawns_data": found 21444 removable, 15445 nonremovable row
> versions in 770 pages

but you've got a spectacularly bad case of index bloat.  An index 50
times bigger than its table is Not Good.  I think you'd find that
"REINDEX TABLE shawns_data" does wonders for the situation.

The next question is how it got to be that way... what is your
vacuuming policy for this database?  Maybe you need to raise
max_fsm_pages?

			regards, tom lane