Re: Per tuple overhead, cmin, cmax, OID

On Tue, 21 May 2002 11:53:04 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
wrote:
>The system tables that have OIDs will certainly continue to have OIDs.

That's clear. I should have written: "... rip out oids from tuple
headers of system tables."

>Ugh. While certainly we should have been using accessor
>macros for that, I'm not sure I want to try to change it.

I already did this for xmin, xmax, cmin, cmax, and xvac (see my patch
posted 2002-05-12).

>If OID is made to be the last fixed-offset field, instead of the first,

That would introduce some padding.

>then this approach would be fairly workable. Actually I'd still use
>just one struct definition, but do offsetof() calculations to decide
>where the null-bitmap starts.

... and for calculating the tuple header size.

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

Just to be sure: You mean the CPU cycles wasted by Pack() and
Unpack()?

>I'd be afraid to use a conversion-in-place tool for this sort of thing.

Me too. No, not in place! I thought of a filter reading an old
format data file, one page at a time, and writing a new format data
file. This would work as long as the conversions don't cause page
overflow.

No comment on a planned 7.3 timeframe? :-(

Servus
Manfred