Обсуждение: HeapTupleHeader withoud oid

We have been discussing heap tuple header changes for a while now.
Here is my proposal for omitting the oid, when it is not needed:

First let's eliminate t_oid from HeapTupleHeaderData.

Then add the oid to the end of the structure, if and only if it is
needed.  The tricky part here is that there is a variable length field
(t_bits) and the oid has to be properly aligned.

This pseudo code snippet illustrates what I plan to do:
len = offsetof(HeapTupleHeaderData, t_bits);  /* 23 */if (hasnulls) {    len += BITMAPLEN(NumberOfAttributes);}if
(hasoid){    len += sizeof(Oid);}len = MAXALIGN(len);hoff = len;oidoff = hoff - sizeof(Oid);
 

#define HeapTupleHeaderGetOid(hth) \( *((Oid *)((char *)(hth) + (hth)->t_hoff - sizeof(Oid))) )

And this is how the structure would look like:              1         2           3    0   4     0         0  34  78
2
now  oooo<---------fix--------->.x___X___
+oid <---------fix--------->.oooox___       MAXALIGN 4
+oid <---------fix--------->.....ooooX___   MAXALIGN 8
-oid <---------fix--------->.X___

1:
now  oooo<---------fix--------->bx___X___
+oid <---------fix--------->boooox___       MAXALIGN 4
+oid <---------fix--------->b....ooooX___   MAXALIGN 8
-oid <---------fix--------->bX___

2:
now  oooo<---------fix--------->bb...X___
+oid <---------fix--------->bb...ooooX___   MAXALIGN 4 und 8
-oid <---------fix--------->bb...x___X___                                    3       4 
6:                                   2   6   0
now  oooo<---------fix--------->bbbbbb...x___X___
+oid <---------fix--------->bbbbbb...oooox___       MAXALIGN 4
+oid <---------fix--------->bbbbbb.......ooooX___   MAXALIGN 8
-oid <---------fix--------->bbbbbb...X___

where
<---------fix--------->  fixed sized part without oid, 23 bytes
oooo  oid, 4 bytes
b     one bitmap byte
.     one padding byte
x     start of data area (= hoff) with 4-byte-alignment
X     start of data area (= hoff) with 8-byte-alignment

Bytes saved on architectures with 4/8 byte alignment:                                 hoff    bytes
natts  bitmaplen  hoff72  oidoff   woo    saved      0          28/32     24    24/24    4/8
1-8    1          28/32     24    24/24    4/8
9-40   2-5        32/32     28    28/32    4/0
41-72  6-9        36/40     32    32/32    4/8

As a first step I've already posted a patch that eliminates direct
access to t_oid.  The final patch will change not much more than the
getter and setter macros.

Problems I have identified so far:

.  heap_formtuple needs a parameter bool withoid
.  Does heap_addheader *always* create a header with oid?
.  Have to check heap_xlog_xxxx routines
.  Occasionally a heap tuple header is copied by memmove.

Comments?

ServusManfred

Manfred Koizar <mkoi-pg@aon.at> writes:
> .  Does heap_addheader *always* create a header with oid?

No.
        regards, tom lane

On Mon, 01 Jul 2002 12:40:35 +0200, I wrote:
>Bytes saved on architectures with 4/8 byte alignment:
>                                  hoff    bytes
>natts  bitmaplen  hoff72  oidoff   woo    saved
>       0          28/32     24    24/24    4/8
>1-8    1          28/32     24    24/24    4/8
>9-40   2-5        32/32     28    28/32    4/0
>41-72  6-9        36/40     32    32/32    4/8

In this table oidoff contains wrong values, it is from my first
approach, where I tried to put oid at the first INTALIGNed position
after t_bits.  The table should be:
      bitmap                        hoff    bytes
natts   len   hoff1  hoff2  oidoff    woo    saved       0      32    28/32   24/28    24      4/8
1-8     1      32    28/32   24/28    24      4/8
9-40    2-5   36/40   32      28     28/32    4/0
41-72   6-9    40    36/40   32/36    32      4/8

where hoff1 is the MAXALIGNed length of the tuple header with a v7.2
compatible tuple header format (with bitmaplen patch included);
hoff2 is the header size after the Xmin/Cid/Xmax patch, which is still
being discussed on -patches and -hackers;
with this proposal, if a table has oids, oidoff is the offset of the
oid and header size equals hoff2;
hoff woo is the header size without oid;
bytes saved is relative to hoff2.

I apologize for the confusion.

ServusManfred

Manfred Koizar <mkoi-pg@aon.at> writes:
> Here is my proposal for omitting the oid, when it is not needed:

I do not think you can make this work unless "has oids" is added to
TupleDescs.  There are too many places where tuples are manipulated
with only a tupdesc for reference.

It might also be necessary to add a "has oid" bit to t_infomask,
so that a tuple's OID can be fetched with *no* outside information,
but I'd prefer to avoid that if possible.  I think adding a tupledesc
parameter to heap_getsysattr might be enough to avoid it.

I'd suggest reworking your "Wrap access to Oid" patch, which currently
increases instead of reducing the dependency on access to a Relation
for the tuple.  Also, you could be a little more conservative about
adding Asserts --- those are not free, at least not from a development
point of view, so I object to adding multiple redundant Asserts in
hotspot routines.
        regards, tom lane