Re: Automatic free space map filling

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Automatic free space map filling
Date: 2006-03-01 17:51:59
Message-ID: 20060301175159.GA7490@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > Tom Lane wrote:
> >> How does an optimistic FSM entry avoid the need to run vacuum?
>
> > It ensures that all freed tuples are already in the FSM.
>
> That has nothing to do with it, because the space isn't actually free
> for re-use until vacuum deletes the tuple.

I think the idea is a different "free space map" of sorts, whereby a
transaction that obsoletes a tuple puts its block number in that map. A
transaction that inserts a new tuple goes to the FSM. If nothing is
found, it then goes to the new map. A block returned from that map is
then scanned and any tuple that's no longer visible for anyone is
reused.

The problem with this idea is scanning the block and for each tuple
determine if it's alive. Essentially, we would be folding the "find
dead tuples and compress page" logic, which is currently in vacuum, back
to insert. IMHO this is unacceptable from a performance PoV.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-03-01 17:59:29 Re: [SQL] Interval subtracting
Previous Message Bruce Momjian 2006-03-01 17:48:53 Re: 8.2 Feature Freeze Rough Estimate