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