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

Re: Incorrect behaviour when using a GiST index on points

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-10-02 17:58:40
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


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


In response to


pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-10-02 18:06:14
Subject: Re: Prevent restored WAL files from being archived again Re: Unnecessary WAL archiving after failover
Previous:From: Tom LaneDate: 2012-10-02 17:16:16
Subject: Re: Hash id in pg_stat_statements

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