Re: Revitalising VACUUM FULL for 8.3

Ühel kenal päeval, N, 2007-03-01 kell 14:32, kirjutas Hannu Krosing:

> If we can trust FSM, the whole process just becomes the backward scan
> and null updates until the null update does not move tuple to a lower
> page. Also, for the duration of COMPACT TABLE the updated tuple should
> always be placed in lowes available slot, that is no same-page updates
> should be tied before going to FSM.
> 
> This has some downsides :
> 
> 1 - the original xmin will be lost
> 
> 2 - as with any updates, it may block/abort other concurrent updates, so
> it could be a good thing to teach the update mechanism about null
> updates.
> 
> Still I think that this would be the chepest way to get VACUUM FULL
> behaviour without locking the whole table for long time

This means that

VACUUM FULL mytable; 

would translate to:

VACUUM mytable;  -- make free space
COMPACT mytable; -- move tuples in a bunch of small transactions                -- might have a GUC for max trx length
VACUUM mytable;  -- free the tuples at the end and give space back to fs


-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com