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

From Scott Marlowe
Subject Re: Really really slow select count(*)
Date
Msg-id AANLkTi=NAyNcmhMX5J3X5q2R7KgAO1XkTX=Afue_XZaN@mail.gmail.com
Whole thread Raw
In response to Re: Really really slow select count(*)  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Really really slow select count(*)
List pgsql-performance
On Fri, Feb 4, 2011 at 11:38 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> You don't turn it on; it's a one time operation that does a cleanup.  It is
> by far the easiest way to clean up the mess you have right now.  Moving
> forward, if you have max_fsm_pages set to an appropriate number, you
> shouldn't end up back in this position again.  But VACUUM along won't get
> you out of there, and VACUUM FULL is always a worse way to clean this up
> than CLUSTER.

note that for large, randomly ordered tables, cluster can be pretty
slow, and you might want to do the old:

begin;
select * into temporaryholdingtable order by somefield;
truncate oldtable;
insert into oldtables select * from temporaryholdingtable;
commit;

for fastest performance.  I've had Cluster take hours to do that the
above does in 1/4th the time.

pgsql-performance by date:

Previous
From: Robert Haas
Date:
Subject: Re: How to best use 32 15k.7 300GB drives?
Next
From: Josh Berkus
Date:
Subject: Write-heavy pg_stats_collector on mostly idle server