Ü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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
