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 по дате отправления: