Best ways around memory Error on large st_union for overlay processing

[Paul Ramsey]

It's hard!
I was just thinking that a light snap using the ST_ReducePrecision might
also be good to avoid the generation of some super-tiny slivers, but
whether that's done during preprocessing of rings or using
ST_CoverageSimplify after polygons are re-formed is an unknown. I look
forward to your blog post!
P

On Thu, Jan 15, 2026 at 5:59 PM Mike Treglia <mtreglia at gmail.com> wrote:

> 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/20260116/9a662027/attachment.htm>