Re: t_self as system column

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: t_self as system column
Дата
Msg-id AANLkTim6nwSVPbA9_7m_xv4Vy5C_ehWfRAJz3o9_0AAu@mail.gmail.com
обсуждение исходный текст
Ответ на Re: t_self as system column  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: t_self as system column  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: t_self as system column  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>> I have a strong suspicion that's going to be a, ahem, challenging
>> project.  But it would be great to have.  Getting rid of the system
>> column entries from pg_attribute is probably easy by comparison.
>
> It will be a bit invasive, but I'm not so sure that it's difficult, just a
> mass of details to take care of. Like you I'd be very glad to see it done.

I guess we'll find out...!

>> When we discussed this previously, Tom suggested that we might want to
>> have a three-tiered structure: (1) permanent identifier (never
>> changes, used by other system catalogs to reference the attribute in
>> question), (2) display position, and (3) physical storage position.
>> I'm not sure if it's feasible to think about splitting out (2) and (3)
>> in a single patch, but either one would be useful by itself.  Which
>> are you planning to work on?
>
> Why wouldn't it be feasible?

Just because it might be too much to do all at once.

> In any case, having a mutable logical column
> position is the feature that's been most requested.

I think that's true.  But the physical storage position would give us
a performance benefit, by allowing us to try to avoid useless
alignment padding.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: keepalives on MacOS X
Следующее
От: Tom Lane
Дата:
Сообщение: Re: t_self as system column