Re: GiST penalty functions [PoC]
От | Andrew Borodin |
---|---|
Тема | Re: GiST penalty functions [PoC] |
Дата | |
Msg-id | CAJEAwVEKgCL2P_-x9ve3aZq2xztyP4+vmRuZsxkiNRAsg7GiDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: GiST penalty functions [PoC] (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: GiST penalty functions [PoC]
|
Список | 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 по дате отправления: