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

From Tom Lane
Subject Re: Per tuple overhead, cmin, cmax, OID
Date
Msg-id 20307.1021989452@sss.pgh.pa.us
Whole thread Raw
In response to Re: Per tuple overhead, cmin, cmax, OID  (Manfred Koizar <mkoi-pg@aon.at>)
Responses Re: Per tuple overhead, cmin, cmax, OID  (Manfred Koizar <mkoi-pg@aon.at>)
Re: Per tuple overhead, cmin, cmax, OID  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [GENERAL] Psql 7.2.1 Regress tests failed on RedHat7.3
Next
From: "Dave Page"
Date:
Subject: Re: More schema queries