Re: Per tuple overhead, cmin, cmax, OID
От | Bruce Momjian |
---|---|
Тема | Re: Per tuple overhead, cmin, cmax, OID |
Дата | |
Msg-id | 200206070601.g5761eI23070@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Per tuple overhead, cmin, cmax, OID (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Per tuple overhead, cmin, cmax, OID
|
Список | pgsql-hackers |
Tom Lane wrote: > Manfred Koizar <mkoi-pg@aon.at> writes: > > what about WITHOUT OIDS? I know dropping the OID from some tables and > > keeping it for others is not trivial, because t_oid is the _first_ > > field of HeapTupleHeaderData. I'm vaguely considering a few possible > > implementations and will invest more work in a detailed proposal, if > > it's wanted. > > Yeah, I had been toying with the notion of treating OID like a user > field --- ie, it'd be present in the variable-length part of the record > if at all. It'd be a bit tricky to find all the places that would need > to change, but I think there are not all that many. > > As usual, the major objection to any such change is losing the chance > of doing pg_upgrade. But we didn't have pg_upgrade during the 7.2 > cycle either. If we put together several such changes and did them > all at once, the benefit might be enough to overcome that complaint. I think it is inevitable that there be enough binary file changes the pg_upgrade will not work for 7.3 --- it just seems it is only a matter of time. One idea is to allow alternate page layouts using the heap page version number, but that will be difficult/confusing in the code. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
В списке pgsql-hackers по дате отправления: