Re: Another idea for dealing with cmin/cmax

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Another idea for dealing with cmin/cmax
Дата
Msg-id 20060929140941.GB90915@nasby.net
обсуждение исходный текст
Ответ на Re: Another idea for dealing with cmin/cmax  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Ответы Re: Another idea for dealing with cmin/cmax  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, Sep 29, 2006 at 01:15:06PM +0900, ITAGAKI Takahiro wrote:
> 
> "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.

Dumb question... wouldn't getting down to 20 bytes buy us something?
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


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

Предыдущее
От: Markus Schaber
Дата:
Сообщение: Re: send()/receive() and on-disk storage
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Block B-Tree concept