From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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 17:23:46 |
Message-ID: | 15230.1205774626@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>> 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.
> Can we call them "maps" or "metadata maps"? "forks" sounds weird.
I'm not wedded to "forks", that's just the name that was used in the
only previous example I've seen. Classic Mac had a "resource fork"
and a "data fork" within each file.
Don't think I like "maps" though, as (a) that prejudges what the
alternate forks might be used for, and (b) the name fails to be
inclusive of the data fork. Other suggestions anyone?
BTW, thinking about the Mac precedent a little more, I believe
the way they grafted that Classic concept onto BSD was that
applications (which the user thinks of as single objects) are
now directories with multiple files inside them. Probably it'd be
overkill to think of turning each relation into a subdirectory, but
then again maybe not?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2008-03-17 17:38:38 | Re: New style of hash join proposal |
Previous Message | Bruce Momjian | 2008-03-17 17:17:22 | Re: Commit fest? |