Re: equal() perf tweak

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

In response to

Responses

Browse pgsql-hackers by date

  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...

Browse pgsql-patches by date

  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