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

From Heikki Linnakangas
Subject Re: Another idea for dealing with cmin/cmax
Date
Msg-id 451BF497.9080505@enterprisedb.com
Whole thread Raw
In response to Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Responses Re: Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-hackers
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.

And it's certainly a lot more complicated than the phantom id thing.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Another idea for dealing with cmin/cmax
Next
From: Stefan Kaltenbrunner
Date:
Subject: Re: -HEAD planner issue wrt hash_joins on dbt3 ?