| From: | Andrew Borodin <borodin(at)octonica(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Михаил Бахтерев <mob(at)k(dot)imm(dot)uran(dot)ru>, 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-08 11:51:43 |
| Message-ID: | CAJEAwVEsCk-3pMVk8d6SgH5ewEyQVVQ2kZfvU5LwosFqaq6gMA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>BTW, would someone explain to me why using a float here will not fail catastrophically for inputs outside the range of float?
Indeed, it will. And that's one of the reason I'm considering
advancing GiST API instead of advancing extensions.
It won't crash, but will produce terrible index, not suitable of
performing efficient queries.
GiST treats penalty this way:
/* disallow negative or NaN penalty */
if (isnan(penalty) || penalty < 0.0)
penalty = 0.0;
Any NaN is a "perfect fit".
Calculation of real (say float) penalty and choice of subtree with
smallest penalty is an idea from 92. Modern spatial index requires
more than just a float to compare subtrees.
Best regards, Andrey Borodin, Octonica & Ural Federal University.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Convey | 2016-09-08 12:24:27 | Re: Suggestions for first contribution? |
| Previous Message | Pavel Stehule | 2016-09-08 11:42:47 | Re: \timing interval |