Re: Another idea for dealing with cmin/cmax - Mailing list pgsql-hackers

From ITAGAKI Takahiro
Subject Re: Another idea for dealing with cmin/cmax
Date
Msg-id 20060929115833.5CAC.ITAGAKI.TAKAHIRO@oss.ntt.co.jp
Whole thread Raw
In response to Re: Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Responses 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>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: New version of money type
Next
From: "Joshua D. Drake"
Date:
Subject: Re: JAVA Support