<div dir="ltr"><div class="gmail_default" style="font-size:small">Thanks to both of you. I tried running with perf now and found most of the time was spent in libstdc++ doing dynamic casting and related functions for 80% of CPU time. Within geos itself, the top time spent is in the SimplePoitnInAreaLocator and STRIntersectsOp functions.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't know how geos works well enough to say of this is a related issue.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">TSW<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 2, 2019 at 11:40 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_292948540974063477WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)">There is was an issue with ST_Union as applied to invalid polygons introduced in 3.7.1 and 3.6.2 which would make ST_Union run indefinitely.  It appears to still be an open bug.  This smells like that issue.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><a href="https://trac.osgeo.org/geos/ticket/867" target="_blank">https://trac.osgeo.org/geos/ticket/867</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><a href="https://lists.osgeo.org/pipermail/postgis-users/2018-April/042710.html" target="_blank">https://lists.osgeo.org/pipermail/postgis-users/2018-April/042710.html</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><b><span style="font-size:11pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11pt;font-family:"Calibri",sans-serif"> postgis-users [mailto:<a href="mailto:postgis-users-bounces@lists.osgeo.org" target="_blank">postgis-users-bounces@lists.osgeo.org</a>] <b>On Behalf Of </b>Trevor Wiens<br><b>Sent:</b> Friday, August 2, 2019 1:16 PM<br><b>To:</b> PostGIS Users Discussion <<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>><br><b>Subject:</b> Re: [postgis-users] ST_ConcaveHull performance issue<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">Thanks for your reply. It was mix of points, lines and polygons, but when I broke it down it was the lines causing the problem.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I tried commenting out the line in the ST_ConcaveHull function you suggested but that doesn't make a difference. I suspect there is some underlying library that has changed.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I will open a ticket as you suggest.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">TSW<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Aug 1, 2019 at 11:55 PM Darafei "Komяpa" Praliaskouski <<a href="mailto:me@komzpa.net" target="_blank">me@komzpa.net</a>> wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><p class="MsoNormal">Hi,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">There were changes ST_ConcaveHull that fixed robustness of it in 2.2 -> 2.5 chain.<br>To point where the penalty comes from, try to run a query and on a side console server-side run `sudo perf top`. Function names will get you a rough idea where the execution process lives now.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal" style="margin-bottom:12pt">To further debug, go to blame view in github and try updating st_concavehull (it's in SQL) change by change. Most recent adds an union here, try commenting it out and hot reloading on your db. <a href="https://github.com/postgis/postgis/blame/svn-trunk/postgis/postgis.sql.in#L6155" target="_blank">https://github.com/postgis/postgis/blame/svn-trunk/postgis/postgis.sql.in#L6155</a><u></u><u></u></p></div><div><p class="MsoNormal">Can you share the data and ticket this on <a href="http://trac.osgeo.org/postgis/" target="_blank">http://trac.osgeo.org/postgis/</a>? <br><br>What is the data structurally? Are these 6000 objects points, or polygons?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Fri, Aug 2, 2019 at 3:43 AM Trevor Wiens <<a href="mailto:tsw.web@gmail.com" target="_blank">tsw.web@gmail.com</a>> wrote:<u></u><u></u></p></div><blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal">I am having difficulty determining why I'm seeing significant differences in performance between two database configurations with the same data.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">One one machine (centos) I have the following software:<u></u><u></u></p></div><div><p class="MsoNormal">geos 3.5.0<u></u><u></u></p></div><div><p class="MsoNormal">sfcgal 1.3.1<u></u><u></u></p></div><div><p class="MsoNormal">cgal 4.7.1<u></u><u></u></p></div><div><p class="MsoNormal">postgis 2.2<u></u><u></u></p></div><div><p class="MsoNormal">postgresql 9.4<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">On a second machine (debian 10) I have the following:<u></u><u></u></p></div><div><p class="MsoNormal">geos 3.7.1<u></u><u></u></p></div><div><p class="MsoNormal">sfcgal 1.3.6<u></u><u></u></p></div><div><p class="MsoNormal">cgal 4.13<u></u><u></u></p></div><div><p class="MsoNormal">postgis 2.5.2<u></u><u></u></p></div><div><p class="MsoNormal">postgresql 9.6<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">In terms of hardware there is no significant difference, if anything the second machine is more capable, but that is not reflected in my performance results.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">On the first machine when I run a ST_ConcaveHull with about 6000 features, I get result a second or two. On the second machine, it won't finish within 30 minutes. Both are using geos as the postgis.backend. I don't understand why the one is so much faster than the other with the identical data and query.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Any suggestions as to what to what the cause may be or how I might diagnose the cause?<u></u><u></u></p></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><span class="gmail-m_292948540974063477gmaildefault">Any clues would be greatly appreciated.</span><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">TSW<u></u><u></u></p></div></div><p class="MsoNormal">_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal">-- <u></u><u></u></p><div><div><div><div><p class="MsoNormal">Darafei Praliaskouski<u></u><u></u></p></div><div><p class="MsoNormal">Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a><u></u><u></u></p></div></div></div></div><p class="MsoNormal">_______________________________________________<br>postgis-users mailing list<br><a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><br clear="all"><br>-- <u></u><u></u></p><div><div><div><div><div><div><p class="MsoNormal">Trevor Wiens<br>Apropos Information Systems<br><a href="http://aproposinfosystems.com" target="_blank">aproposinfosystems.com</a><br>Calgary, Alberta<u></u><u></u></p></div><p class="MsoNormal">Ph. 403-973-5901<u></u><u></u></p></div></div></div></div></div></div></div>_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>Trevor Wiens<br>Apropos Information Systems<br><a href="http://aproposinfosystems.com" target="_blank">aproposinfosystems.com</a><br>Calgary, Alberta<br></div>Ph. 403-973-5901</div></div></div></div></div>