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

From Jim C. Nasby
Subject Re: Another idea for dealing with cmin/cmax
Date
Msg-id 20060928162223.GO34238@nasby.net
Whole thread Raw
In response to Re: Another idea for dealing with cmin/cmax  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Another idea for dealing with cmin/cmax  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
List pgsql-hackers
On Thu, Sep 28, 2006 at 05:13:11PM +0100, Heikki Linnakangas wrote:
> Jim C. Nasby wrote:
> >In addition to/instead of abstracting cmin/cmax to a phantom ID, what
> >about allowing for two versions of the tuple header, one with cid info
> >and one without? That would allow for cid info to be stripped out when
> >pages were written to disk.
> >  
> 
> How exactly would that help? You can't just strip out cid info when 
> writing to disk, if you don't want to lose the information.

Erm, sorry, brainfart... yeah, we'd need to be able to write the info
out to disk.

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.

The problem with *that* is that (AFAIK) you'll need cid info again once
you go to update or delete that tuple. And that might obviously need to
spill to disk before the transaction commits.

Back to the drawing board...
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: [GENERAL] 'pg_ctl -w' times out when unix_socket_directory is
Next
From: "Luke Lonergan"
Date:
Subject: Re: New version of money type