<div dir="ltr"><div><div>Hello everyone,</div><div><br></div><div>I have a question regarding the row estimations/gist indexes. Here's a minimal reproduction of it:</div><div><br></div><div>create table test(p geometry(point));<br>insert into test(p) values (st_makepoint(1,1));<br>insert into test(p) values (st_makepoint(1,2));<br>insert into test(p) values (st_makepoint(2,1));<br>insert into test(p) values (st_makepoint(2,2));<br>insert into test(p) values (st_makepoint(51,1));<br>analyze test;<br>explain analyze select * from test where ST_Contains(ST_GeomFromText('POLYGON((0 0,3 -0,3 3,0 3,0 0))'), p);<br>explain analyze select * from test where ST_Contains(ST_GeomFromText('POLYGON((50 0,52 0,52 2,50 2,50 0))'), p);<br></div><div><br></div><div>The two queries get the same cost/row estimation, of 1 row. This is the EXPLAIN ANALYZE of the first query:</div><div><br></div><div>Seq Scan on test  (cost=0.00..126.05 rows=1 width=32) (actual time=0.015..0.022 rows=4 loops=1)<br>   Filter: st_contains('01030000000100000005000000000000000000F0BF000000000000F0BF0000000000000040000000000000F0BF00000000000000400000000000000040000000000000F0BF0000000000000040000000000000F0BF000000000000F0BF'::geometry, p)<span style="color:rgb(80,0,80)"><br>   Rows Removed by Filter: 1<br></span> Planning Time: 0.072 ms<br> Execution Time: 0.035 ms<br>(5 rows)<br></div><div><br></div><div>What I was expecting is the first query to estimate 4 rows and the second to estimate 1, like what I get If I try the same thing using integers.</div><div><br></div><div>create table test(x integer, y integer);<br>insert into test(x, y) values (0, 0);<br>insert into test(x, y) values (0, 1);<br>insert into test(x, y) values (1, 0);<br>insert into test(x, y) values (1, 1);<br>insert into test(x, y) values (50, 0);<br>analyze test;<br>explain analyze select * from test where x between 0 and 1 and y between 0 and 1;<br>explain analyze select * from test where x between 50 and 51 and y between 0 and 1;<br></div><div><br></div><div>My question is: is this expected behaviour? I actually have a much larger table with a gist index where I found this occurring, and this causes the planner to make bad decisions: every query that I do will have the same estimation, and whenever this estimation is very wrong, the planner does not take the optimal decision when it has to compare with other indexes costs in a more complicated query.</div><div><br></div><div>I'm using the official docker image, PostgreSQL 15.1 (Debian 15.1-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit POSTGIS="3.3.1 3786b21" [EXTENSION] PGSQL="150" GEOS="3.9.0-CAPI-1.16.2" PROJ="7.2.1" LIBXML="2.9.10" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)" TOPOLOGY</div><div><br></div><div>Best regards,</div><div>Igor</div></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"></div></div>