> > > 		-- start the VACUUM from the first non-filled block
> > > 
> > > So if we do this, we wouldn't need to worry about HOT tuples at
all, 
> > > nor would we need to wait until all transactions are gone.
> > 
> > You need to wait until you are allowed to truncate if you want 
> > concurrency.
> > Or a concurrent scan might miss a row, because the visible tuple got

> > truncated away.
> 
> I was not suggesting that we remove visible rows through truncation.

Sure, unless you suggest to not truncate during this vacuum run ?
But we are talking about vacuum full, so truncation is essential.

It was suggested to do a dummy null update to move live tuples up front.
The old version is still visible for serializable txns.

Andreas

In response to

• Re: Revitalising VACUUM FULL for 8.3 at 2007-03-01 13:41:44 from Simon Riggs

Responses

• Re: Revitalising VACUUM FULL for 8.3 at 2007-03-01 14:54:44 from Hannu Krosing

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2007-03-01 14:06:41
	Subject: Re: [HACKERS] Deadlock with pg_dump?
Previous:	From: Pavan Deolasee	Date: 2007-03-01 14:00:52
	Subject: HOT WIP Patch - version 4.0