Tom Lane wrote:
We could fix this by changing the declarations of the "maxoff" variables to int, but I think it's probably cleaner to recode PageGetMaxOffsetNumber like so:
#define PageGetMaxOffsetNumber(page) \ (((PageHeader) (page))->pd_lower <= SizeOfPageHeaderData ? 0 : \ ((((PageHeader) (page))->pd_lower - SizeOfPageHeaderData) \ / sizeof(ItemIdData)))
Well I think that is safe change:
a <= b ? 0 : ( a-b ) /c
in
max( 0, (a-b)/c )
so I think (not tested) you can rewrite that macro in:
#define PageGetMaxOffsetNumber(page) \ (max(0, ((((PageHeader) (page))->pd_lower - SizeOfPageHeaderData) \ / sizeof(ItemIdData))))
Hi all, no reply yet! I did this post in a provocative way. Let me explain.
I know that most probably the max function is written in this way:
int max(int a, int b) { return a < b ? b : a; }so this means obtain almost the Tom's proposal.
I seen that usually postgres rpm distributed code, I think a big percentage of postgres installation is used by an rpm, is compiled without taking care of the architecture. Am I wrong ?
make now some benchmark using these two implementation:
(a) int max(int a, int b) { return a < b ? b : a; }or this unusual version:
(b) int max(int a, int b) { int i = -(a > b); return (a & i)|(b & ~i); }make an order of 10E6 maxing compiling your program without specify the -march parameter. Do the same specifying if you can -march=pentium3 or -march=pentium4
what I see on my pentiumIII is 100% of improvement, I didn't believe this improvement just avoid ( I think ) dead branch, specifying the architecture. So, am I hand waving/red herring ? May be yes, but my conclusion (wrong as always in this list :-) ) is: if we don't specify the architecture as we do => it's better use the nifty ( IMHO ) max implementation => is better write my suggested macro ( with the opposite max implementation of course ).
Regards Gaetano Mendola
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
