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