Re: Multi-Versions and Vacuum

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: grant <grant(at)amadensor(dot)com>, Anthony Berglas <anthony(dot)berglas(at)lucida(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Multi-Versions and Vacuum
Date: 2002-07-19 16:35:23
Message-ID: 13524.1027096523@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> grant wrote:
>> Q: Does VACUUM FULL remove the rows that are too many for the FSM? Or,
>> are they just stuck? I know that regular VACUUM will not allow reuse of
>> overflowed rows.

You seem to know things that aren't true. What is an "overflowed row"
anyway?

> VACUUM full removes all unused rows from disk _including_ ones that
> aren't in the free space map.

The FSM isn't interested in individual rows in the first place; it just
records the amount of free space per *page*.

After VACUUM does its thing (and yes, it removes everything it legally
can) it reports the amount of free space it found on each page to the
FSM, and the FSM remembers as much of that info as it has room for ---
preferring pages with more free space, if it has to be selective.
Subsequently, when any backend needs to add a tuple to a relation, it
first looks in the FSM to see if there is an extant page with enough
room. If there's no suitable entry in the FSM, then try the last extant
page; if no luck there, add a new page.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Wolff III 2002-07-19 16:45:18 Re: Looking for types: phone number, email addresses
Previous Message grant 2002-07-19 16:20:10 Re: Multi-Versions and Vacuum