Re: trying to use CLUSTER
От | Albe Laurenz |
---|---|
Тема | Re: trying to use CLUSTER |
Дата | |
Msg-id | A737B7A37273E048B164557ADEF4A58B057B2B29@ntex2010a.host.magwien.gv.at обсуждение исходный текст |
Ответ на | trying to use CLUSTER ("Sahagian, David" <david.sahagian@emc.com>) |
Ответы |
trying to use CLUSTER
|
Список | pgsql-general |
David Sahagian wrote: > Version=3D9.1.7 >=20 > INFO: clustering "my_cool_table" using sequential scan and sort > INFO: "my_cool_table": found 1 removable, 1699139 nonremovable row versio= ns in 49762 pages > Detail: 1689396 dead row versions cannot be removed yet. > CPU 9.80s/4.98u sec elapsed 175.92 sec. > My expectation is that a VERY SMALL percentage of the row versions would = actually get written to the > new table! > Can somebody tell me why some "dead row versions cannot be removed yet" ? >=20 > I assume that means CLUSTER must write them to the new table ? I would say so. The dead rows probably cannot be removed because of a long running transaction. Is there a reason why you use CLUSTER and not VACUUM FULL? Does VACUUM FULL show the same symptoms (dead row versions cannot be removed yet)? > Is there a way for me to discover the approx number of "non-removables" B= EFORE I do the CLUSTER ? > ? Some pg_table query ? maybe after an analyze ? SELECT n_live_tup, n_dead_tup FROM pg_stat_all_tables WHERE relname =3D 'my_cool_table'; > Also, does the use of [index scan on "pk_cool"] basically depend on the r= atio of > removable/nonremovable row versions ? I guess it will use whatever is cheaper (faster). Yours, Laurenz Albe
В списке pgsql-general по дате отправления: