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
|
Список | 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 по дате отправления: