<div dir="ltr"><div>Hi,</div><div><br></div><div>There are two issues that I believe should be resolved in different ways:</div><div><br></div><div> - Memory free on cancellation: let's check how it really works. Having 2x memory used on GSERIALIZED (disk) -> LWGEOM (palloc) and LWGEOM (palloc) -> GEOS (malloc) might have been non-issue when there was a hard limit of 1GB memory usage, but 6GB vs 12GB means swap versus non-swap (hours vs days potentially, but proper benchmark is yet to do) on many machines. I believe there has to be a cancellation callback or a wrap-up flag of some kind. </div><div><br></div><div>Can GEOS live in palloc'd memory?</div><div><br></div><div> - Upgrade issues: pushing all the internal functions to keep the same signature, when their nature is different, just for the sake of backward compatibility is not a sustainable way forward. </div><div>Thanks Sandro for providing a test case for upgrades, I'll try to tackle it within two weeks when we have holidays in Belarus.</div><div><br></div><div>Another reason to not keep signature and instead work on extension install code is that <a href="https://lists.osgeo.org/pipermail/postgis-devel/2019-April/027887.html">https://lists.osgeo.org/pipermail/postgis-devel/2019-April/027887.html</a> suggests that parallel union may be possible, and that improvement by itself will also require ST_Union signature alteration. I believe I've seen comments from Martin on GEOSUnion redesign, so even an old implementation may suddenly become feasible.</div><div><br></div><div>Thoughts?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"> On Mon, Apr 29, 2019 at 8:52 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</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">So, this issue I feel is still not resolved,<br>
<br>
<a href="https://github.com/postgis/postgis/pull/394" rel="noreferrer" target="_blank">https://github.com/postgis/postgis/pull/394</a><br>
<br>
We've got an open ticket now now on upgrades potentially having issues<br>
if they use ST_Union() in aggregates. I also have an open question<br>
with respect to memory leaks in the case of query cancellation.<br>
<br>
I feel like a less intrusive implementation would be to not convert<br>
the individual geometries to GEOS in the transfer function, but to<br>
collect them in an LWCOLLECTION instead, and do the work of conversion<br>
and processing in the final function.<br>
<br>
This would allow us to keep the shared transfn signature and avoid the<br>
upgrade issues, and would also keep all the memory in the PgSQL memory<br>
manager right up until finalfn, so cancellation during collection<br>
becomes a non-issue. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'll do this work if nobody else will, gritting my teeth as I do so,<br>
since it's churn for a relatively rare use case (collecting more than<br>
1GB of inputs for an output that will fit in less than 1GB).<br>
<br>
P.<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_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></div>