On Fri, Feb 04, 2011 at 05:20:27PM +0100, felix wrote: > reply was meant for the list > > ---------- Forwarded message ---------- > From: felix <crucialfe...@gmail.com> > Date: Fri, Feb 4, 2011 at 4:39 PM > Subject: Re: [PERFORM] Really really slow select count(*) > To: Greg Smith <g...@2ndquadrant.com> > > > > > On Fri, Feb 4, 2011 at 3:56 PM, Greg Smith <g...@2ndquadrant.com> wrote: > > > PostgreSQL version? If you're running on 8.3 or earlier, I would be > > suspicous that your Free Space Map has been overrun. > > > > 8.3 > > > > > > > What you are seeing is that the table itself is much larger on disk than > > it's supposed to be. > > > > which part of the explain told you that ? > > > shaun thomas > > SELECT relpages*8/1024 FROM pg_class > WHERE relname='fastadder_fastadderstatus'; > > 458MB > > way too big. build_cache is text between 500-1k chars >
As has been suggested, you really need to CLUSTER the table to remove dead rows. VACUUM will not do that, VACUUM FULL will but will take a full table lock and then you would need to REINDEX to fix index bloat. CLUSTER will do this in one shot. You almost certainly have your free space map way too small, which is how you bloated in the first place. Cheers, Ken -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
