[HACKERS] 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 -fix-.x___X___ +oid -fix-.x___ MAXALIGN 4 +oid -fix-.X___ MAXALIGN 8 -oid -fix-.X___ 1: now -fix-bx___X___ +oid -fix-bx___ MAXALIGN 4 +oid -fix-bX___ MAXALIGN 8 -oid -fix-bX___ 2: now -fix-bb...X___ +oid -fix-bb...X___ MAXALIGN 4 und 8 -oid -fix-bb...x___X___ 3 4 6: 2 6 0 now -fix-bb...x___X___ +oid -fix-bb...x___ MAXALIGN 4 +oid -fix-bb...X___ MAXALIGN 8 -oid -fix-bb...X___ where -fix- fixed sized part without oid, 23 bytes 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: hoffbytes natts bitmaplen hoff72 oidoff woosaved 0 28/32 2424/244/8 1-81 28/32 2424/244/8 9-40 2-532/32 2828/324/0 41-72 6-936/40 3232/324/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_ routines . Occasionally a heap tuple header is copied by memmove. Comments? Servus Manfred ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] HeapTupleHeader withoud oid
Manfred Koizar [EMAIL PROTECTED] writes: . Does heap_addheader *always* create a header with oid? No. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] HeapTupleHeader withoud oid
Manfred Koizar [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]