Re: Rewriting Free Space Map - Mailing list pgsql-hackers

From Lars-Erik Bjørk
Subject Re: Rewriting Free Space Map
Date
Msg-id 1205762010.13711.0.camel@falcon
Whole thread Raw
In response to Re: Rewriting Free Space Map  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, 2008-03-17 at 09:29 -0400, Tom Lane wrote:
> Hannu Krosing <hannu@krosing.net> writes:
> > On Sun, 2008-03-16 at 21:33 -0300, Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> The idea that's becoming attractive to me while contemplating the
> >>> multiple-maps problem is that we should adopt something similar to
> >>> the old Mac OS idea of multiple "forks" in a relation.
> 
> > Are'nt we in a way doing this for indexes ?
> 
> Not really --- indexes are closer to being independent entities, since
> they have their own relfilenode values, own pg_class entries, etc.  What
> I'm imagining here is something that's so tightly tied to the core heap
> that there's no value in managing it as a distinct entity, thus the idea
> of same relfilenode with a different extension.  The existence of
> multiple forks in a relation wouldn't be exposed at all at the SQL
> level.
> 
> >> I think something similar could be used to store tuple visibility bits
> >> separately from heap tuple data itself, so +1 to this idea.
> 
> > Not just "bits", but whole visibility info (xmin,xmax,tmin,tmax, plus
> > bits) should be stored separately.
> 
> I'm entirely un-sold on this idea, but yeah it would be something that
> would be possible to experiment with once we have a multi-fork
> infrastructure.
> 
>             regards, tom lane
> 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Rewriting Free Space Map
Next
From: Alvaro Herrera
Date:
Subject: Re: [0/4] Proposal of SE-PostgreSQL patches