From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rewriting Free Space Map |
Date: | 2008-03-17 00:33:02 |
Message-ID: | 20080317003301.GA18580@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-03-17 01:31:38 | Re: Commit fest? |
Previous Message | Tom Lane | 2008-03-16 22:42:35 | Re: Single table forcing sequential scans on query plans |