<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">> Thanks for the test data.  In my Java environment intersection computes in<br>> 3.8 s  :)    That is definitely one of the gnarlier polygon geometries I've<br>> seen - even worse than muskeg lakes :)<br>> </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Wow 3.8 sec is that the old version or the one with the envelope check?</div><div class="gmail_default" style="font-size:small">Still puzzling why postgres @work, devpc at home and your system differ by that much...</div><div class="gmail_default" style="font-size:small">Thought cpu's are more or less comparable these days...</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">
<div class="gmail_default" style="font-size:small">> Also, the covers predicate computes in 1.3 s, so adding that test into the<br>> path would definitely be beneficial - for this particular case.  This is<br>> pretty data-specific, though - it depends how many cases in the overall<br>> computation allow short-circuiting via that test.  Did you try the PostGIS<br>> query using the combination of predicates and intersection?<br>></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Certainly wouldn't add that if it takes about 30% of the time, and I'm not sure if I have the full picture of all the edgecases</div><div class="gmail_default" style="font-size:small">Did try quite some combinations of predicate and intersections. predicares took about 40s, intersection about 60<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"> <br>> So maybe a pre-evaluation covers check is best left as an option to the<br>> Overlay code, so that intermediate structures can be reused.  In other<br>> words, provide an optional flag on the Overlay operation which does a<br>> covers check before computing the full result, utilizing the internal<br>> segment indexing to perform the check quickly.<br>> <br>> And as you say, if this can be prepared it should make an even bigger<br>> difference.  This requires knowing which side of the operation is the one<br>> that should be prepared - is this obvious in your data context?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Yes, that's the one covering the world.</div><div class="gmail_default" style="font-size:small">In the mean time, I learnt from the code that in case of overlap there will be expensive computations done, so I rewrote (actually: planning to :) ) my queries from st_intersection(geo,"world-country") to st_difference(geo,"country"). As the "county" is much smaller, a lot of stuff can be calculated just based on envelope.<br></div><div class="gmail_default" style="font-size:small">Did a test, and one of the queries that took over 30 hours was now done in 18 hours, so that's quite an improvement. Only drawback is that having some queries with a st_difference and some with st_intersection isn't helping in the clarity of the whole workflow... Added benefit is that with the st_difference, I don't get line and point geometries that are on the boundary<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">What would help in this case is probably an idea I posted here: <a href="https://lists.osgeo.org/pipermail/postgis-users/2018-December/043029.html">https://lists.osgeo.org/pipermail/postgis-users/2018-December/043029.html</a><br></div><div class="gmail_default" style="font-size:small"><br></div>

</div></div></div></div>