<div dir="ltr">Hi Paul,<div><br></div><div>Do you plan to keep this function present but "hidden" for 2.5 ?</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 22, 2018 at 2:50 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Oh, I neglected to mention: some performance queries and results<br>
catalogued here, using my favourite BC political boundaries data (poly<br>
vs poly).<br>
<br>
<a href="https://gist.github.com/pramsey/9638940582bd45d74c7d0fb1d47f6083" rel="noreferrer" target="_blank">https://gist.github.com/pramsey/9638940582bd45d74c7d0fb1d47f6083</a><br>
<br>
I suppose some tests with points/lines in particular would help to<br>
confirm cut-off points for complexity.<br>
<br>
P<br>
<br>
<br>
On Thu, Feb 22, 2018 at 11:46 AM, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> wrote:<br>
> I have now added a _ST_DistanceRectTreeCached(geom, geom) that does<br>
> caching, so for cases with nested loop joins we should see improved<br>
> performance. There's still cases (small geom vs small geom) that are<br>
> handled better with the existing code. And I recall that Nik found<br>
> some large cases that are degenerate too?<br>
> Anyways, it seems like the final implementation of Distance() will end<br>
> up being a hodgepodge with some magic number rules in the middle<br>
> determining which code line to use.<br>
> P<br>
><br>
><br>
> On Tue, Feb 20, 2018 at 1:53 PM, Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</a>> wrote:<br>
>> OK, it's in there, for those who want to try it out,<br>
>> _ST_DistanceRectTree(g1 geometry, g2 geometry)<br>
>> There is no caching in this version, so it's building and tossing away<br>
>> the trees at every invocation.<br>
>> P.<br>
>><br>
>> On Tue, Feb 20, 2018 at 1:49 PM, Bborie Park <<a href="mailto:dustymugs@gmail.com" target="_blank">dustymugs@gmail.com</a>> wrote:<br>
>>> +1<br>
>>><br>
>>> On Tue, Feb 20, 2018 at 12:14 PM, Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> wrote:<br>
>>>><br>
>>>> No objections from me. +1 to just bring it in 2.5.<br>
>>>><br>
>>>> I'm too lazy to test another branch, but if in place, I'd be willing to<br>
>>>> test it out.<br>
>>>><br>
>>>> Thanks,<br>
>>>> Regina<br>
>>>><br>
>>>> -----Original Message-----<br>
>>>> From: postgis-devel [mailto:<a href="mailto:postgis-devel-bounces@lists.osgeo.org" target="_blank">postgis-devel-bounces@lists.osgeo.org</a>] On<br>
>>>> Behalf Of Paul Ramsey<br>
>>>> Sent: Tuesday, February 20, 2018 2:26 PM<br>
>>>> To: PostGIS Development Discussion <<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a>><br>
>>>> Subject: [postgis-devel] RectDistance<br>
>>>><br>
>>>> Hey all,<br>
>>>> I've had a branch running for a while, that Nik has tested a little, for<br>
>>>> tree-based distance calculations. I've been doing some testing on it and<br>
>>>> finding that when it's good, it's very very good (10x improvements when<br>
>>>> dealing with large geometries) and when it's bad, it's not so great (3x<br>
>>>> worse than existing naive distance on small-vs-small geometries).<br>
>>>> All this so far without also reaching into the next obvious enhancement,<br>
>>>> adding a caching behaviour, like the point-in-polygon/geos code. That will<br>
>>>> make everything about 2x faster yet, as about 50% of the time seems to be<br>
>>>> spent in building up trees.<br>
>>>> I'd like to merge my branch in, along with a temporary testing function<br>
>>>> _ST_DistanceRectTree(geom, geom) so that we can figure out how we exactly<br>
>>>> want to put this code to use. Any objections? If nothing else, it will<br>
>>>> replace the current dead code lying in lwtree.c.<br>
>>>><br>
>>>> P.<br>
>>>> _______________________________________________<br>
>>>> postgis-devel mailing list<br>
>>>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>>>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> postgis-devel mailing list<br>
>>>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>>>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> postgis-devel mailing list<br>
>>> <a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
>>> <a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div>