Re: Another idea for dealing with cmin/cmax

Поиск
Список
Период
Сортировка
От ITAGAKI Takahiro
Тема Re: Another idea for dealing with cmin/cmax
Дата
Msg-id 20060929115833.5CAC.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Another idea for dealing with cmin/cmax  (Heikki Linnakangas <heikki@enterprisedb.com>)
Re: Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-hackers
"Jim C. Nasby" <jim@nasby.net> wrote:

> The reason I thought of this is because once the transaction commits, we
> have no use for the cid info. So we could do something like have
> bgwriter look for tuples that belong to committed transactions before it
> writes a page, and strip the cid out of them.

Your concept is just like as the experimental method that I suggested before
in http://archives.postgresql.org/pgsql-hackers/2005-08/msg01193.php
We can remove cmin and cmax from commited tuples and xmin from frozen tuples
and we might save some bytes in tuple headers.

However, I think our next goal to shrink the headers is 16 bytes. The headers
become 23 bytes using phantom cids and we are limited by alignments, so we will
have no more advantages unless we delete extra 7 bytes in the headers.
...and it seems to be very difficult.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New version of money type
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: JAVA Support