<div dir="ltr">(now it's me needing to remind you to cross-post to the list  :)<div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr">On Wed, Dec 5, 2018 at 10:59 AM Paul van der Linden <<a href="mailto:paul.doskabouter@gmail.com">paul.doskabouter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small">> <span class="gmail_default"></span>Hmmm - is this because st_difference includes an envelope check?  In PostGIS or GEOS? </div><div style="font-size:small"><br></div><div style="font-size:small">It's because most (just not the ones fully within the hole) of the forests do intersect with "world-hole" and thus trigger the expensive operation of noding, testing self-intersect and whatnot, while the st_difference only triggers that for polygons intersecting with that hole.</div></div></blockquote><div><br></div><div>So if I understand this, the difference is actually between the "positive" of the holes in the "world-hole polygon" and forest polys which intersect it?  If so that makes sense. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">And as for getting lines and polygons out of an intersection isn't that bad, just add a st_collectionextract and all will be fine.</div></div></blockquote><div><br></div><div>Right... maybe that's good enough.  Although there might be a bit of performance improvement possible if the overlay ops know what is wanted ahead of time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:small"><br></div><div style="font-size:small">
<div><div><span class="gmail_default" style="font-size:small"></span>> select ST_IntersectionPrepared(geomA, geomB) R </div><div>> from A join B on A.geom && B.geom</div><div>> where R != empty/null</div></div><div><br></div><div>That would indeed be perfect! At least if that doesn't involve calculating st_intersection twice...<br></div></div></div></blockquote><div><br></div><div>Good to know that makes sense.  I'm not sure how the preparation caching will work, but am hoping to understand that better soon.  And to have time to work on this improvement - which should be a win for a lot of users. </div></div></div>