Re: Really really slow select count(*) - Mailing list pgsql-performance

From Kenneth Marshall
Subject Re: Really really slow select count(*)
Date
Msg-id 20110204162702.GE1261@aart.is.rice.edu
Whole thread Raw
In response to Really really slow select count(*)  (felix <crucialfelix@gmail.com>)
List pgsql-performance
On Fri, Feb 04, 2011 at 05:20:27PM +0100, felix wrote:
> reply was meant for the list
>
> ---------- Forwarded message ----------
> From: felix <crucialfelix@gmail.com>
> Date: Fri, Feb 4, 2011 at 4:39 PM
> Subject: Re: [PERFORM] Really really slow select count(*)
> To: Greg Smith <greg@2ndquadrant.com>
>
>
>
>
> On Fri, Feb 4, 2011 at 3:56 PM, Greg Smith <greg@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

pgsql-performance by date:

Previous
From: felix
Date:
Subject: Really really slow select count(*)
Next
From: Shaun Thomas
Date:
Subject: Re: Really really slow select count(*)