Re: Number of attributes in HeapTupleHeader

--
Rod
----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Manfred Koizar" <mkoi-pg(at)aon(dot)at>
Cc: "Rod Taylor" <rbt(at)zort(dot)ca>; "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>;
"Neil Conway" <nconway(at)klamath(dot)dyndns(dot)org>;
<pgsql-hackers(at)postgresql(dot)org>
Sent: Wednesday, May 08, 2002 4:54 PM
Subject: Re: [HACKERS] Number of attributes in HeapTupleHeader

> This has been discussed before --- in PG terms, it'd mean keeping
the
> OID of a rowtype in the tuple header. (No, I won't let you get away
> with a 1-byte integer. But you could remove natts and hoff, thus
> buying back 3 of the 4 bytes.)

Could the OID be on a per page basis? Rather than versioning each
tuple, much with a page at a time? Means when you update one in a
page the rest need to be tested to ensure that they have the most
recent type, but it certainly makes storage requirements smaller when
Toast isn't involved (8k rows).

> I was actually going to suggest it again earlier in this thread; but
> people weren't excited about the idea last time it was brought up,
> so I decided not to bother. It'd be a *lot* of work and a lot of
> breakage of existing clients (eg, pg_attribute would need to link
> to pg_type not pg_class, pg_class.relnatts would move to pg_type,
> etc etc). The flexibility looks cool, but people seem to feel that
> the price is too high for the actual amount of usefulness.

There would be no cost if we had an information schema of somekind.
Just change how the views are made. Getting everything to use the
information schema in the first place is tricky though...