
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Jan 15, 2026, at 9:46 AM, Mike Treglia <mtreglia@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><div style="caret-color: rgb(0, 0, 0); font-family: HelveticaNeue; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Is there an obvious or more optimal way to do that st_union(st_exteriorring(geom)) step for large datasets? </div><br class="Apple-interchange-newline"></div></blockquote></div><br><div>Just spitballing…</div><div><br></div><div>Starting with an ST_Subdivide on all the rings, writing out the ring segments and a unique key into a staging table.</div><div>Then do the st_union on a gridded basis. I think that should be safe?</div><div>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.</div><div>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.</div><div>P.</div></body></html>