On Mon, Dec 15, 2014 at 7:47 PM, Heikki Linnakangas <hlinnakan...@vmware.com > wrote: > > On 12/15/2014 05:22 PM, Alexander Korotkov wrote: > >> On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >>> >>> Alexander Korotkov <aekorot...@gmail.com> writes: >>> >>>> On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas < >>>> >>> hlinnakan...@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. >> > > Right. I don't think point <-> polygon is too useful by itself, but we > need an example in core that could make use KNN-GiST recheck patch. We > can't write a regression test for it otherwise, for starters. > > Actually, we probably could've used the circle <-> polygon for that just > as well...
Did you mean searching for circles or polygons in the last sentence? ------ With best regards, Alexander Korotkov.
