Re: Per tuple overhead, cmin, cmax, OID - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Per tuple overhead, cmin, cmax, OID
Date
Msg-id 200206070601.g5761eI23070@candle.pha.pa.us
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Per tuple overhead, cmin, cmax, OID
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Per tuple overhead, cmin, cmax, OID
Next
From: Bruce Momjian
Date:
Subject: Re: Use of /etc/services?