From: | Andrew Borodin <borodin(at)octonica(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, mike(dot)bakhterev(at)gmail(dot)com |
Subject: | Re: GiST penalty functions [PoC] |
Date: | 2016-09-01 13:00:36 |
Message-ID: | CAJEAwVEKgCL2P_-x9ve3aZq2xztyP4+vmRuZsxkiNRAsg7GiDw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 this heavily 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-09-01 13:03:44 | Re: Missing checks when malloc returns NULL... |
Previous Message | Tom Lane | 2016-09-01 12:47:09 | Re: GiST penalty functions [PoC] |