Re: Another idea for dealing with cmin/cmax

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Another idea for dealing with cmin/cmax
Дата
Msg-id 451BF497.9080505@enterprisedb.com
обсуждение исходный текст
Ответ на Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Another idea for dealing with cmin/cmax  ("Jim C. Nasby" <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Another idea for dealing with cmin/cmax
Следующее
От: Stefan Kaltenbrunner
Дата:
Сообщение: Re: -HEAD planner issue wrt hash_joins on dbt3 ?