Skip site navigation (1) Skip section navigation (2)

Re: Revitalising VACUUM FULL for 8.3

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Revitalising VACUUM FULL for 8.3
Date: 2007-03-01 12:42:51
Message-ID: 1172752971.3216.21.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Ü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:

In response to


pgsql-hackers by date

Next:From: Simon RiggsDate: 2007-03-01 12:56:46
Subject: Re: Revitalising VACUUM FULL for 8.3
Previous:From: Hannu KrosingDate: 2007-03-01 12:32:24
Subject: Re: Revitalising VACUUM FULL for 8.3

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group