On Mon, 2008-03-17 at 09:29 -0400, Tom Lane wrote: > 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
