Hannu Krosing <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
