Re: Incorrect behaviour when using a GiST index on points

On Tue, Aug 28, 2012 at 05:04:09PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

I agree in the abstract; why should a point (position on a 2D plane) compare
fuzzily while a float8 (position on a 1D number line) does not? But ...

> > 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.

... yes. Having never used these types in practice, I won't venture a guess.
Anyone else?

> 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.

Definitely.

> 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.

In any event, I think we should entertain a patch to make the GiST operator
class methods bug-compatible with corresponding operators. Even if we decide
to change operator behavior in HEAD, the back branches could use it.

Thanks,
nm