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

Re: Incorrect behaviour when using a GiST index on points

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-29 03:08:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
The Enterprise PostgreSQL Company

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-08-29 03:11:09
Subject: Re: 64-bit API for large object
Previous:From: Robert HaasDate: 2012-08-29 02:58:02
Subject: Re: MySQL search query is not executing in Postgres DB

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