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