Re: Per tuple overhead, cmin, cmax, OID

On Tue, 21 May 2002 09:57:32 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>Manfred Koizar <mkoi-pg(at)aon(dot)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.
That was one of the possible solutions I thought of, unfortunately the
one I'm most afraid of. Not because I think it's not the cleanest
way, but I don't (yet) feel comfortable enough with the code to rip
out oids from system tables. However, if you tell me it's feasible
and if you give me some hints where to start, I'll give it a try...

Other possible implementations would leave the oid in the tuple
header:

. typedef two structs HeapTupleHeaderDataWithOid and
HeapTupleHeaderDataWithoutOid, wrap access to *all* HeapTupleHeader
fields in accessor macros/functions, give these accessors enough
information to know which variant to use.

. Decouple on-disk format from in-memory structures, use
HeapTupleHeaderPack() and HeapTupleHeaderUnpack() to store/extract
header data to/from disk buffers. Concurrency?

>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.

I thought, it is quite common to need pg_dump/restore when upgrading
between releases. Or are you talking about those hackers, testers and
users(?), who are using a cvs version now?

Anyway, as long as our changes don't make heap tuples larger, it
should be possible to write a tool that converts version x data files
to version y data files. I've done that before (not for PG though)
and I know it's a lot of work, but wouldn't it be great for the PG
marketing department ;-)

>If we put together several such changes [...]

I can't guarantee that; my ideas come in drop by drop :-)
BTW, is there a 7.3 schedule?

Servus
Manfred