Re: Incorrect behaviour when using a GiST index on points - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Incorrect behaviour when using a GiST index on points
Date
Msg-id 9804.1346187849@sss.pgh.pa.us
Whole thread Raw
In response to Re: Incorrect behaviour when using a GiST index on points  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Incorrect behaviour when using a GiST index on points
Re: Incorrect behaviour when using a GiST index on points
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> There's also the big-picture question of whether we should just get rid
>> of fuzzy comparisons in the geometric types instead of trying to hack
>> indexes to work around them.

> +1 for that approach, but only if I don't have to do the work.
> Otherwise, +1 for doing the simplest thing that we're sure will
> eliminate wrong answers.

What we're forced to speculate about here is how many applications out
there are relying on fuzzy comparison to get answers they like, versus
how many are getting answers they don't like because of it.  The fact
that the underlying storage is float8 not numeric suggests there are
probably some cases where fuzzy is helpful.

Another issue here is that even if we agree that simple comparisons
(operator complexity up to about the limit of what an index might
support) should be exact, there's something to be said for fuzzy
computations for operators like whether a point falls on a line.
Internal roundoff error makes that problematic even if you assume
that the inputs are exact.

I've never cared for the particulars of the way the fuzzy comparisons
are done, in any case: using an absolute rather than relative error
threshold is wrong according to every numerical analysis principle
I know.

The long and the short of it is that it will probably take a significant
investment of work to make something that's clearly better.  If that
weren't the case, we'd have done something long ago.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: temporal support patch
Next
From: Jim Nasby
Date:
Subject: Re: Audit Logs WAS: temporal support patch