Re: vacuum full 100 mins plus?

Answered my own question. I gave up the vacuum full after 150 mins. I was
able to export to a file, vacuum full the empty table, and reimport in less
than 10 mins. I suspect the empty item pointers and the sheer number of
removable rows was causing an issue.

Patrick Hatcher
<PHatcher(at)macys(dot)c
om> To
Sent by: pgsql-performance(at)postgresql(dot)org
pgsql-performance cc
-owner(at)postgresql
.org Subject
[PERFORM] vacuum full 100 mins
plus?
07/14/2004 02:29
PM

Should I be concerned that my vacuum process has taken upwards of 100 +
minutes to complete? I dropped all indexes before starting and also
increased the vacuum_mem before starting.
Looking at the output below, it appears that a vacuum full hasn't been done
on this table for quite sometime. Would I be better off exporting the data
vacuuming the table and reimporting the data? I cannot drop the table do
to views attached to the table

mdc_oz=# set vacuum_mem = 10240;
SET
mdc_oz=# vacuum full verbose cdm.cdm_ddw_Tran_item;
INFO: vacuuming "cdm.cdm_ddw_tran_item"
INFO: "cdm_ddw_tran_item": found 15322404 removable, 10950460 nonremovable
row versions in 934724 pages
DETAIL: 0 dead row versions cannot be removed yet.
Nonremovable row versions range from 233 to 308 bytes long.
There were 1081 unused item pointers.
Total free space (including removable row versions) is 4474020460 bytes.
544679 pages are or will become empty, including 0 at the end of the table.
692980 pages containing 4433398408 free bytes are potential move
destinations.
CPU 29.55s/4.13u sec elapsed 107.82 sec.

TIA
Patrick Hatcher

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend