From: | Andrew Borodin <borodin(at)octonica(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Teodor Sigaev <teodor(at)postgrespro(dot)ru>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Greg S <stark(at)mit(dot)edu> |
Subject: | GiST: interpretation of NaN from penalty function |
Date: | 2016-09-14 17:23:42 |
Message-ID: | CAJEAwVFxCbEYM157McVqQrvg7CQthxF2UdXw0sZCjLvW7cekQw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi hackers!
Currently GiST treats NaN penalty as zero penalty, in terms of
generalized tree this means "perfect fit". I think that this situation
should be considered "worst fit" instead.
Here is a patch to highlight place in the code.
I could not construct test to generate bad tree, which would be fixed
by this patch. There is not so much of cases when you get NaN. None of
them can be a result of usual additions and multiplications of real
values.
Do I miss something? Is there any case when NaN should be considered good fit?
Greg Stark was talking about this in
BANLkTi=d+bPpS1cM4YC8KuKHj63Hwj4LMA(at)mail(dot)gmail(dot)com but that topic
didn't go far (due to triangles). I'm currently messing with floats in
penalties, very close to NaNs, and I think this question can be
settled.
Regrads, Andrey Borodin.
Attachment | Content-Type | Size |
---|---|---|
gist_nan_penalty.diff | text/plain | 751 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2016-09-14 17:23:54 | Re: Vacuum: allow usage of more than 1GB of work mem |
Previous Message | Andrew Borodin | 2016-09-14 16:57:08 | Re: GiST penalty functions [PoC] |