Re: equal() perf tweak

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Neil Conway <neilc(at)samurai(dot)com>
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:28:38
Message-ID: 16364.1068096518@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Neil Conway <neilc(at)samurai(dot)com> writes:
> 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?

Not really. I'll go with ordering fields in a logical fashion (related
fields together) every time. But when there's no particular semantic
reason to choose one ordering over another, you might as well look at
padding concerns for a tiebreaker. In this case there isn't any
particular logical reason AFAICS to prefer whether length appears before
or after head/tail, so why not pick the more compact form?

(Note that I put a higher premium on avoiding padding in on-disk
structures. But for transient in-memory structures, it definitely
seems like a secondary consideration.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2003-11-06 05:34:04 Re: Schema boggle...
Previous Message Neil Conway 2003-11-06 05:11:19 Re: equal() perf tweak

Browse pgsql-patches by date

  From Date Subject
Next Message Gaetano Mendola 2003-11-06 10:49:11 Re: equal() perf tweak
Previous Message Neil Conway 2003-11-06 05:11:19 Re: equal() perf tweak