number of attributes in page files?

Started by Mario Weilguniover 23 years ago3 messages
#1Mario Weilguni
mweilguni@sime.com

Is it possible to get rid of the "t_natts" fields in the tuple header? Is this field only for "alter table add/drop" support? Then it might
possible to get rid of it and put the "t_natts" field in the page header, not the tuple header, if it can be assured that when updating/inserting
records only a compatible (a page file with the same number of attributes) page file is used. Especially master-detail tables would
profit from this, reducing the tuple overhead by another 9%.

Might this be possible?

Regards,
Mario Weilguni

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mario Weilguni (#1)
Re: [HACKERS] number of attributes in page files?

Mario Weilguni <mweilguni@sime.com> writes:

Is it possible to get rid of the "t_natts" fields in the tuple header?
Is this field only for "alter table add/drop" support?

"Only"? A lot of people consider that pretty important ...

But removing 2 bytes isn't going to save anything, on most machines,
because of alignment considerations.

regards, tom lane

#3Mario Weilguni
mweilguni@sime.com
In reply to: Tom Lane (#2)
Re: [HACKERS] number of attributes in page files?

Am Freitag, 11. Oktober 2002 14:12 schrieb Tom Lane:

Mario Weilguni <mweilguni@sime.com> writes:

Is it possible to get rid of the "t_natts" fields in the tuple header?
Is this field only for "alter table add/drop" support?

"Only"? A lot of people consider that pretty important ...

With "only" I mean it's an administrative task which requires operator intervenation anyways, and it's a seldom needed operation which may take longer, when
queries become faster.

But removing 2 bytes isn't going to save anything, on most machines,
because of alignment considerations.

ok, I did not consider alignment, but the question remains, is this easily doable? Especially because only one another byte has to be saved for
real saving on many architectures, which is t_hoff. IMO t_hoff is not useful because it can be computed easily. This would give 20 byte headers instead of 23 (24) bytes as it's now.
This is 17% saved, and if it's not too complicated it might be worth to consider.

Best regards,
Mario Weilguni