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. In addition > > to the main data fork which contains the same info as now, there could > > be one or more map forks which are separate files in the filesystem. > > I think something similar could be used to store tuple visibility bits > separately from heap tuple data itself, so +1 to this idea. > > (The rough idea in my head was that you can do an indexscan and look > up visibility bits without having to pull the whole heap along; and > visibility updates are also cheaper, whether they come from indexscans > or heap scans. Of course, the implicit cost is that a seqscan needs to > fetch the visibility pages, too; and the locking is more complex.)
I very much like the idea of a generic method for including additional bulk metadata for a relation (heap or index). That neatly provides a general infrastructure for lots of clever things such as dead space, visibility or other properties, while at the same time maintaining modularity. Can we call them "maps" or "metadata maps"? "forks" sounds weird. We don't need to assume anything about the maps themselves at this stage, so we might imagine tightly coupled maps that are always updated as a relation changes, or loosely coupled maps that are lazily updated by background processes. Autovacuum then becomes the vehicle by which we execute "map maintenance" procedures, defined according to which AMs are installed and what relation options are set. So we have a completely generalised data/metadata storage infrastructure. Sensibly arranged this could provide an entry point for powerful new features within existing and future index AMs. It also sounds like it might avoid a whole class of bugs and special cases that I regrettably foresee would be unavoidable in Heikki's proposal. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
