<div dir="ltr"><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I will open a ticket as you suggest.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Thanks</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 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:<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 dir="ltr">Hi,<div><br></div><div>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.</div><div><br></div><div>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><br><br></div><div>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?</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<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 dir="ltr"><div class="gmail_default" style="font-size:small">I am having difficulty determining why I'm seeing significant differences in performance between two database configurations with the same data.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One one machine (centos) I have the following software:</div><div class="gmail_default" style="font-size:small">geos 3.5.0</div><div class="gmail_default" style="font-size:small">sfcgal 1.3.1</div><div class="gmail_default" style="font-size:small">cgal 4.7.1</div><div class="gmail_default" style="font-size:small">postgis 2.2</div><div class="gmail_default" style="font-size:small">postgresql 9.4</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">On a second machine (debian 10) I have the following:</div><div class="gmail_default" style="font-size:small">geos 3.7.1<br></div><div style="font-size:small" class="gmail_default">sfcgal 1.3.6</div><div style="font-size:small" class="gmail_default">cgal 4.13</div><div style="font-size:small" class="gmail_default">postgis 2.5.2</div><div style="font-size:small" class="gmail_default">postgresql 9.6</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">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.<br></div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">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.</div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">Any suggestions as to what to what the cause may be or how I might diagnose the cause?<br></div><br><div><span class="gmail_default" style="font-size:small">Any clues would be greatly appreciated.</span><span class="gmail_default" style="font-size:small"></span></div><div style="font-size:small" class="gmail_default"><br></div><div style="font-size:small" class="gmail_default">TSW</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"><div><br></div>-- <br><div dir="ltr" class="gmail-m_9147776399264241056gmail-m_-7016787863109085547gmail_signature"><div dir="ltr"><div><div>Darafei Praliaskouski</div><div>Support me: <a href="http://patreon.com/komzpa" target="_blank">http://patreon.com/komzpa</a></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-m_9147776399264241056gmail_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>