
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body class=""><div>Well, it is not redundant if one of the tables have many rows and the other just a few.</div><div><br></div><div>Then it is 50 % chance that you get the wrong plan without both tests.</div><div><br></div><div><br></div><div>/Nicklas</div><div><br></div><div><br></div><div><br></div><div>On Sat, 2018-01-06 at 11:10 -0500, Zhihong Zhang wrote:</div><blockquote type="cite">Thanks for the explanation. I understand the reason for the 2nd check now.<div class=""><br class=""></div><div class="">All our geometry columns are indexed so the 2nd check is redundant, which causes the performance degradation.</div><div class=""><br class=""></div><div class="">Zhihong</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 6, 2018, at 11:00 AM, Nicklas Avén <<a href="mailto:nicklas.aven@jordogskog.no" class="">nicklas.aven@jordogskog.no</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div class="">Hello</div><div class=""><br class=""></div><div class="">If you get a difference as large as 20% I guess you are not using spatial indexes.</div><div class=""><br class=""></div><div class="">The reaason for that implementation is that it gives the query planner the possibility to choose if it shall iterate table1 and use the index of table 2 to find overlaps, or if it shall iterate table 2 instead and use the index of table 1 to find overlap.</div><div class=""><br class=""></div><div class="">The index cannot be used on an expanded geometry (snce the bbox in the index is for the original geometry) so without this double check the planner wouldn't have the choice.</div><div class=""><br class=""></div><div class="">That would be very bad if only 1 of the tables have an index. It is also a bad thing if the table that gets the sequential scan is the one with millions of rows and the index is used on the table with just a few rows.</div><div class=""><br class=""></div><div class="">/Nicklas</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">On Sat, 2018-01-06 at 10:14 -0500, Zhihong Zhang wrote:</div><blockquote type="cite" class="">ST_DWithin is implemented like this,<div class=""><br class=""></div><div class=""></div><div class=""><font color="#24292e" face="Courier New" class=""><span style="font-size: 14px;" class="">CREATE OR REPLACE FUNCTION ST_DWithin(geom1 geometry, geom2 geometry, float8 RETURNS boolean</span></font><table class="highlight js-file-line-container tab-size" data-tab-size="8" style="orphans: 2; widows: 2; box-sizing: border-box; border-spacing: 0px; border-collapse: collapse; tab-size: 8; background-color: rgb(255, 255, 255);"></table><font color="#24292e" face="Courier New" class=""><span style="font-size: 14px;" class="">AS 'SELECT $1 OPERATOR(@extschema@.&&) @extschema@.ST_Expand($2,$3) AND <b class="">$2 OPERATOR(@extschema@.&&) @extschema@.ST_Expand($1,$3)</b> AND @extschema@._ST_DWithin($1, $2, $3)'</span></font><table class="highlight js-file-line-container tab-size" data-tab-size="8" style="orphans: 2; widows: 2; box-sizing: border-box; border-spacing: 0px; border-collapse: collapse; tab-size: 8; background-color: rgb(255, 255, 255);"></table><font color="#24292e" face="Courier New" class=""><span style="font-size: 14px;" class="">LANGUAGE 'sql' IMMUTABLE _PARALLEL;</span></font><table class="highlight js-file-line-container tab-size" data-tab-size="8" style="orphans: 2; widows: 2; box-sizing: border-box; border-spacing: 0px; border-collapse: collapse; tab-size: 8; background-color: rgb(255, 255, 255);"></table><div class=""><br class=""></div></div><div class="">What’s the purpose of the second bounding box check? </div><div class=""><br class=""></div><div class="">I did many tests. It’s always faster (about 20%) with one check. So we ended up using our own version of ST_DWithin.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class=""><br class=""></div><div class="">Zhihong</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><pre class="">_______________________________________________

postgis-devel mailing list

<a href="mailto:postgis-devel@lists.osgeo.org" class="">postgis-devel@lists.osgeo.org</a>

<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></pre></blockquote></div>_______________________________________________<br class="">postgis-devel mailing list<br class=""><a href="mailto:postgis-devel@lists.osgeo.org" class="">postgis-devel@lists.osgeo.org</a><br class="">https://lists.osgeo.org/mailman/listinfo/postgis-devel</div></blockquote></div><br class=""></div><pre>_______________________________________________

postgis-devel mailing list

<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a>

<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></pre></blockquote></body></html>