Re: Commit fest 2014-12, let's begin! - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Commit fest 2014-12, let's begin!
Date
Msg-id CAPpHfduLhBAmOCR=HpWvKe0dQF5Ea3McccJSxRMkydBWc88UgA@mail.gmail.com
Whole thread Raw
In response to Re: Commit fest 2014-12, let's begin!  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Commit fest 2014-12, let's begin!  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
> On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas <hlinnakangas@vmware.com
>> wrote:
>> Right. I also looked at it briefly, but I wasn't sure if we really want
>> it. AFAICT, no-one has actually asked for that operator, it was written
>> only to be an example of an operator that would benefit from the knn-gist
>> with recheck patch.

> Lack of recheck is major limitation of KNN-GiST now. People are not asking
> for that because they don't know what is needed to implement exact KNN for
> PostGIS. Now they have to invent kluges like this:
> [ query using ORDER BY ST_Distance ]

It's not apparent to me that the proposed operator is a replacement for
ST_Distance.  The underlying data in an example like this won't be either
points or polygons, it'll be PostGIS datatypes.

In short, I believe that PostGIS could use what you're talking about,
but I agree with Heikki's objection that nobody has asked for this
particular operator.

"polygon <-> point" is for sure not ST_Distance replacement. I was giving this argument about KNN-GiST with recheck itself. "polygon <-> point" is needed just as in-core example of KNN-GiST with recheck.

------
With best regards,
Alexander Korotkov.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Commit fest 2014-12, let's begin!
Next
From: Tom Lane
Date:
Subject: Re: Join push-down support for foreign tables