Re: Rewriting Free Space Map

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rewriting Free Space Map
Дата
Msg-id 15230.1205774626@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rewriting Free Space Map  (Simon Riggs <simon@2ndquadrant.com>)
Ответы Re: Rewriting Free Space Map  (David Fetter <david@fetter.org>)
Re: Rewriting Free Space Map  (Simon Riggs <simon@2ndquadrant.com>)
Re: Rewriting Free Space Map  ("Jochem van Dieten" <jochemd@gmail.com>)
Re: Rewriting Free Space Map  ("Mark Cave-Ayland" <mark.cave-ayland@siriusit.co.uk>)
Re: Rewriting Free Space Map  (Gregory Stark <stark@enterprisedb.com>)
Re: Rewriting Free Space Map  ("Dawid Kuroczko" <qnex42@gmail.com>)
Re: Rewriting Free Space Map  (tomas@tuxteam.de)
Список pgsql-hackers
Simon Riggs <simon@2ndquadrant.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Rewriting Free Space Map
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Some cleanups of enum-guc code, per comments from Tom.