Re: Commit fest 2014-12, let's begin!
От | Heikki Linnakangas |
---|---|
Тема | Re: Commit fest 2014-12, let's begin! |
Дата | |
Msg-id | 548F1088.3010808@vmware.com обсуждение исходный текст |
Ответ на | Re: Commit fest 2014-12, let's begin! (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: Commit fest 2014-12, let's begin!
|
Список | pgsql-hackers |
On 12/15/2014 05:22 PM, Alexander Korotkov wrote: > 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. 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
В списке pgsql-hackers по дате отправления: