On Tue, Aug 28, 2012 at 5:04 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
