Re: Really really slow select count(*)

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: Really really slow select count(*)
Дата
Msg-id AANLkTi=NAyNcmhMX5J3X5q2R7KgAO1XkTX=Afue_XZaN@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Really really slow select count(*)  (Greg Smith <greg@2ndquadrant.com>)
Ответы Re: Really really slow select count(*)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: How to best use 32 15k.7 300GB drives?
Следующее
От: Josh Berkus
Дата:
Сообщение: Write-heavy pg_stats_collector on mostly idle server