Re: equal() perf tweak - Mailing list pgsql-patches

From Tom Lane
Subject Re: equal() perf tweak
Date
Msg-id 16364.1068096518@sss.pgh.pa.us
Whole thread Raw
In response to Re: equal() perf tweak  (Neil Conway <neilc@samurai.com>)
List pgsql-patches
Neil Conway <neilc@samurai.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

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-hackers-win32] initdb in C
Next
From: Tom Lane
Date:
Subject: Re: Patch 7.4RC1 pgtcl to restore Tcl-8.0 compatibility for large obj fix