On Thu, Apr 21, 2005 at 01:06:13AM -0400, Tom Lane wrote:
> "Jim C. Nasby" <decibel@decibel.org> writes:
> > 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.
>
> We don't have any support for locking sections of a table larger than
> a page, so I'm not clear on how the above could be made to work.
Vacuum full and cluster both lock the entire table, no?
> But in any case, I wasn't talking about vacuum full. I was thinking of
> the total picture in a normal vacuum cycle:
>
> 1. vacuum cleans out dead tuples and records the space in FSM
> 2. ordinary inserts and updates use the space shown in FSM
> 3. next vacuum cleans out the space freed, and shortens the table
> if it can
>
> I believe that step 2 preferentially uses space closer to the front
> of the table, so I think that what you are proposing already happens
> naturally.
Don't updates prefer putting the new tuple on the same page if there's
room available? If so, 2 doesn't really happen nearly as much as it
could. Also, my point was to proactively move tuples, instead of hoping
that they eventually get moved by an update.
Your suggestion also doesn't allow for a background/non-blocking
cluster, unless some code is written that prefferentially puts new
tuples in cluster order.
--
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?"