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]  (Andrew Borodin <borodin@octonica.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: GiST penalty functions [PoC]
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Missing checks when malloc returns NULL...