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
