<div dir="ltr"><div>For those interested, the GEOS performance regression was filed at <a href="https://trac.osgeo.org/geos/ticket/997">https://trac.osgeo.org/geos/ticket/997</a></div><div><br></div><div>A functioning workaround is to call ST_SnapToGrid on the buffered geometry before the union operation, e.g. ST_Union(ST_SnapToGrid(ST_Buffer(...), 0.0001))</div><div><br></div><div>Jason</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 9, 2019 at 2:54 PM Jason Greenlaw - NOAA Affiliate <<a href="mailto:jason.greenlaw@noaa.gov">jason.greenlaw@noaa.gov</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 dir="ltr">I did a bit more testing and determined that the 3.6.1 -> 3.6.2 regression does not actually appear to be the cause.  Instead, performance issues for my use-case seem to have been introduced between 3.6.x -> 3.7.0.<div><br></div><div><div>With PostGIS 2.3.7 / GEOS 3.6.1, query took ~85 seconds on my machine:<div><br></div><div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px"><div>POSTGIS="2.3.7 r16523" PGSQL="95" GEOS="3.6.1-CAPI-1.10.1 r0" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL 1.11.4, released 2016/01/25" LIBXML="2.9.1" LIBJSON="0.11" RASTER<br></div><div><br></div><div>EXPLAIN ANALYZE SELECT ST_Union(ST_Buffer(wkb_geometry, 100.0))::geometry(Geometry, 3857),category,vteccode,prod_type,validtime,starttime,endtime FROM public.nws_haz_hang_201910 GROUP BY  category,vteccode,prod_type,validtime,starttime,endtime;<br>                                                       QUERY PLAN                                                       <br>------------------------------------------------------------------------------------------------------------------------<br> HashAggregate  (cost=10.30..10.45 rows=10 width=706) (actual time=35922.055..85310.959 rows=5 loops=1)<br>   Group Key: category, vteccode, prod_type, validtime, starttime, endtime<br>   ->  Seq Scan on nws_haz_hang_201910  (cost=0.00..10.10 rows=10 width=706) (actual time=0.014..0.053 rows=21 loops=1)<br> Planning time: 0.460 ms<br> Execution time: 85314.516 ms<br>(5 rows)</div></blockquote></div></div></div><div><br></div><div>I got similar timings with GEOS 3.6.2 (90 sec), 3.6.3 (89 sec) and 3.6.4 (100 sec), but when testing with 3.7.0, the command took 70 minutes to finish.</div><div><br></div><div>I've kept the PostGIS version at 2.3 for this round of testing because 2.5 was not working with GEOS 3.6.0 (error about missing function GEOSFrechetDistanceDensify).</div><div><br></div><div>I also tested 3.8.0rc3 (which contains the recent <a href="https://github.com/libgeos/geos/commit/6bac4f45e94f8e18409803b17eb306dd94fa065a#diff-ee28c8845c72c5f8c7307c430276b944" target="_blank">performance fix</a> ported from JTS) with PostGIS 2.5.3, but that too showed severe performance issues for my use-case, with the command finally finishing after 2 hours 27 minutes.</div><div><br></div><div>If anyone has additional insight please let me know.  I will likely do a few more tests and follow up with a GEOS bug report.</div><div><br></div><div>Thanks,</div><div>Jason</div></div>
</div>
</blockquote></div></div>