Re: GiST penalty functions [PoC] - Mailing list pgsql-hackers

From Andrew Borodin
Subject Re: GiST penalty functions [PoC]
Date
Msg-id CAJEAwVEKgCL2P_-x9ve3aZq2xztyP4+vmRuZsxkiNRAsg7GiDw@mail.gmail.com
Whole thread Raw
In response to Re: GiST penalty functions [PoC]  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: GiST penalty functions [PoC]  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
Thank you for your coments, Tom.

> Modern compilers are generally able to make their own decisions about it, and trying to put your thumb on the scales
thisheavily is not likely to improve the code.
 
Well, I have tested that combination of "static inline" affets
performance of index build on a scale of 5%. Though I didn't tested
with "static" only.
AFAIK compiler cannot prove that array of function input and output do
not intersect, so it emits lots of writes to output address inside
loop body.

>That pack_float function is absolutely not acceptable
Well, possibly, there are ways to achive penalty optimization without
such hacks, but it failed for pg_shpere and in PostGIS code. They
reverted plain arithmetic optimization without bit hacks, becuase it
didn't worked. This one works.
There is other way: advance GiST API. But I'm not sure it is possible
to do so without breaking compatibility with many existing extensions.

Best regards, Andrey Borodin, Octonica & Ural Federal University.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: GiST penalty functions [PoC]
Next
From: Tom Lane
Date:
Subject: Re: Missing checks when malloc returns NULL...