Best ways around memory Error on large st_union for overlay processing

[Mike Treglia]

Thanks, Paul! Appreciate these thoughts - and considerations.  I'll keep
these ideas in mind as I proceed and see where I end up.  Definitely trying
to keep things simpler than not all things considered... we'll see!
Best,
Mike

On Thu, Jan 15, 2026 at 1:16 PM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

>
>
> On Jan 15, 2026, at 9:46 AM, Mike Treglia <mtreglia at gmail.com> wrote:
>
> Is there an obvious or more optimal way to do that
> st_union(st_exteriorring(geom)) step for large datasets?
>
>
> Just spitballing…
>
> Starting with an ST_Subdivide on all the rings, writing out the ring
> segments and a unique key into a staging table.
> Then do the st_union on a gridded basis. I think that should be safe?
> The part I worry about is doing the polygon building, unless you do the
> build with overlapping grid cells to select potential input ring segments,
> and then post-filter the polygon collection you get to remove any
> overlapping/duplicated polygons. My concern is that a very large input
> polygon relative to the grid size might fail to be built, if all its
> component pieces do not happen to fall into a single grid cell.
> At some point you end up building something of the scale and complexity of
> the topology module, and maybe you would be able to get some good results
> starting there instead.
> P.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260115/373ce62f/attachment.htm>