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+bpps1cm4yc8kukhj63hwj4...@mail.gmail.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.
diff --git a/src/backend/access/gist/gistutil.c b/src/backend/access/gist/gistutil.c index fac166d..0a62561 100644 --- a/src/backend/access/gist/gistutil.c +++ b/src/backend/access/gist/gistutil.c @@ -675,8 +675,14 @@ gistpenalty(GISTSTATE *giststate, int attno, PointerGetDatum(orig), PointerGetDatum(add), PointerGetDatum(&penalty)); - /* disallow negative or NaN penalty */ - if (isnan(penalty) || penalty < 0.0) + /* + * disallow negative or NaN penalty + * NaN is considered float infinity - i.e. most inapropriate fit + * negative is considered penaltiless fix + */ + if (isnan(penalty)) + penalty = get_float4_infinity(); + if (penalty < 0.0) penalty = 0.0; } else if (isNullOrig && isNullAdd)
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers