Re: Commit fest 2014-12, let's begin!

On 12/15/2014 05:22 PM, Alexander Korotkov wrote:
> On Mon, Dec 15, 2014 at 6:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>> Alexander Korotkov <aekorotkov(at)gmail(dot)com> writes:
>>> On Mon, Dec 15, 2014 at 4:12 PM, Heikki Linnakangas <
>> hlinnakangas(at)vmware(dot)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...

- Heikki