Re: Incorrect behaviour when using a GiST index on points

On Tue, Aug 28, 2012 at 5:04 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.
>> 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.

I figured it mostly ended up that way because most of the geometic
datatypes are built on top of float8s, and most of the GiST distance
metrics are therefore a float8 distance. But I must be confused,
because surely we don't need to remove the option to express the
penalty as a float8, only the prohibition on using anything else. In
which case this next part seems like a non-issue:

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

Yeah, that seemed odd to me, too.

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

Perhaps, but this patch has been kicking around for 7 months without
any on-list review, so there might also be a lack of interest in
fixing the problem. :-(

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company