Skip site navigation (1) Skip section navigation (2)

Re: Incorrect behaviour when using a GiST index on points

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Oleg Bartunov <obartunov(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Incorrect behaviour when using a GiST index on points
Date: 2012-08-28 21:04:09
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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

In response to


pgsql-hackers by date

Next:From: Jim NasbyDate: 2012-08-28 21:06:42
Subject: Re: Audit Logs WAS: temporal support patch
Previous:From: Jim NasbyDate: 2012-08-28 21:02:38
Subject: Re: temporal support patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group