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.) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
