From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Gaetano Mendola <mendola(at)bigfoot(dot)com>, "pgsql-patches(at)postgresql(dot)org" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: equal() perf tweak |
Date: | 2003-11-06 05:11:19 |
Message-ID: | 87ptg6f5e0.fsf@mailbox.samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> This does suggest that it might be worth making the struct layout be
>
> int NodeTag;
> int length;
> foo *head;
> foo *tail;
>
> since this would avoid some padding overhead on a machine where pointers
> are 8 bytes and need 8-byte alignment. It probably doesn't help given
> the current implementation of palloc, but why throw away padding
> space?
Interesting. I've heard in some shops it is standard policy to order
the fields in all structs by their descending sizes (making allowances
for platform-specific variations), so as to reduce padding. Do you
think it would be worthwhile to systematically make this kind of
reorganization throughout the backend?
(Of course, we'd need to be weary of code that depends on order of the
fields in structs, naturally -- such as the "NodeTag must be the first
field" rule.)
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-06 05:28:38 | Re: equal() perf tweak |
Previous Message | Josh Berkus | 2003-11-06 05:01:58 | Re: [HACKERS] Schema boggle... |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-11-06 05:28:38 | Re: equal() perf tweak |
Previous Message | Tom Lane | 2003-11-06 04:16:51 | Re: equal() perf tweak |