Re: Proposal for background vacuum full/cluster - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Proposal for background vacuum full/cluster
Date
Msg-id 20050421044353.GC58835@decibel.org
Whole thread Raw
In response to Re: Proposal for background vacuum full/cluster  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for background vacuum full/cluster  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Apr 20, 2005 at 07:33:54PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > In a nutshell, my idea is to use the normal transactional/XID code to
> > relocate tuples in the heap. Think of doing an UPDATE field=field if you
> > could tell update what page to put the new tuple on. Using this
> > mechanism, you can move tuples from the end of the heap to pages that
> > have free space on them. The dead tuples at the end of the heap could
> > then be vacuumed conventionally, and completely empty pages removed by
> > that vacuum.
> 
> How exactly is this different from what happens now, assuming that you
> didn't run out of FSM?

In the case of cluster I think it's quite different, as cluster
currently re-writes the heap from scratch, no?

I'm not sure how different it is from vacuum full, though the main idea
is that instead of locking the table you instead work in smaller pieces
and don't block anything other than other updates.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords
Next
From: "Jim C. Nasby"
Date:
Subject: Re: Proposal for background vacuum full/cluster