Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] number of attributes in page files?

From: Mario Weilguni <mweilguni(at)sime(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] number of attributes in page files?
Date: 2002-10-11 14:00:13
Message-ID: 200210111600.13876.mweilguni@sime.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Am Freitag, 11. Oktober 2002 14:12 schrieb Tom Lane:
> Mario Weilguni <mweilguni(at)sime(dot)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

In response to

pgsql-performance by date

Next:From: Ludwig LimDate: 2002-10-11 14:34:58
Subject: Re: Compile test with gcc 3.2
Previous:From: Tom LaneDate: 2002-10-11 12:12:50
Subject: Re: [HACKERS] number of attributes in page files?

pgsql-hackers by date

Next:From: Dave CramerDate: 2002-10-11 14:30:30
Subject: Re: Out of memory error on huge resultset
Previous:From: Shridhar DaithankarDate: 2002-10-11 13:40:26
Subject: Re: Peer to peer replication of Postgresql databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group