On Mon, 2008-03-17 at 09:29 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)krosing(dot)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
>