[postgis-devel] RectDistance

[Paul Ramsey]

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180801/2ec2c5b2/attachment.html>