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

Re: Proposal for background vacuum full/cluster

From: Paul Tillotson <pntil(at)shentel(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Proposal for background vacuum full/cluster
Date: 2005-04-22 00:53:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:

>"Jim C. Nasby" <decibel(at)decibel(dot)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.
>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
So if we attempted this, then the missing piece of the puzzle is
        2b. move the tuples out of the end pages of the table using
UPDATE, or using a "special" update that changes no values and fires no
triggers either.


Two questions:

1) Does an update always go to the FSM to find out where to put the new
tuple, or does it first try to put it in the current page, and only read
the FSM if the current page is already full?

2) Is it possible to write a where clause that can efficiently hit only
the tuples in the end of the table?  If there is a way, then I could
test the idea without writing any code at all.

Paul Tillotson

In response to


pgsql-hackers by date

Next:From: Paul TillotsonDate: 2005-04-22 00:53:51
Subject: Re: Proposal for background vacuum full/cluster
Previous:From: Paul TillotsonDate: 2005-04-22 00:52:16
Subject: Re: Postgres: pg_hba.conf, md5, pg_shadow, encrypted passwords

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