<div dir="ltr"><div>Hi Paco,</div><div><br></div><div>How is the query executed in the DB? Is it a prepared query, or are parameters (x, y) passed on the client side and then the resolved query is executed in the DB?</div><div><br></div><div>In case of prepared query, the planner uses a "general" plan to execute the query: the plan is eventually corrected comparing the estimated costs in executing</div><div>the query with the costs of the general plan, or used otherwise. The general plan is computed after the first 5 executions of the query, where execution plans are</div><div>always estimated. From the 6th execution, the planner will try to use the general plan. Although the plan can be corrected basing on the passed parameters to</div><div>the prepared statement, it can lead to odd behaviour since the correction is based on the costs, specially if the statistics related to the table are not properly</div><div>updated.<br></div><div><br></div><div>But please provide more details about how you execute the query.</div><div><br></div><div>Giuseppe.<br></div><div> <br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 24 nov 2020 alle ore 10:23 Calvo Arias, Francisco <<a href="mailto:fcaa@tragsa.es">fcaa@tragsa.es</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="ES">
<div class="gmail-m_7571359562960292075WordSection1">
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m having an issue with the planner using a sequential scan instead of the spatial index over a big table with several millions of geometries. My query is similar to this, where the query parameters are the coordinates for a point:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">select * from my table<u></u><u></u></p>
<p class="MsoNormal">where st_contains(geometry, st_setsrid(st_point(x, y), find_srid('public', 'my_table', 'geometry')))<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This occurs with PostGIS 3.0 ('POSTGIS="3.0.3 3.0.3" [EXTENSION] PGSQL="110" GEOS="3.8.1-CAPI-1.13.3" PROJ="7.1.1" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.4.3 (Internal)"') on Potgres 11 and 9.6, both for Windows and
 fully patched. Works as expected on other instances with Postgres 10 and 12 and PostGIS 2.5.3 and 3.0.3, respectively.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Using other predicates as st_intersection instead of st_contains or reindexing and analyzing the table doesn’t work. Changing find_srid(…) for a constant value uses the expected plan. As a workaround, I’ve extracted the construction of
 the second geometry (st_setsrid(…)) to a CTE, giving a plan similar to the expected one.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I’m thinking of a different configuration of the plannner in those instances with the problem, but I’m not really sure.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Any help is welcome.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><span>Thanks in advance,<u></u><u></u></span></p>
<p class="MsoNormal"><span>Paco Calvo<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote></div>