[PostGIS] #5984: PostGIS selectivity is screwing up queries and forcing it to choose a spatial index when it's inappropriate

[PostGIS]

#5984: PostGIS selectivity is screwing up queries and forcing it to choose a
spatial index when it's inappropriate
-----------------------+---------------------------
  Reporter:  robe      |      Owner:  pramsey
      Type:  defect    |     Status:  new
  Priority:  critical  |  Milestone:  PostGIS 3.4.5
 Component:  postgis   |    Version:  3.5.x
Resolution:            |   Keywords:
-----------------------+---------------------------
Comment (by robe):

 I tried dropping the spatial index and replacing with my btree gist and
 seems to work better than the above two:


 {{{

 DROP INDEX idx_test_nodes_geom;

 CREATE EXTENSION IF NOT EXISTS btree_gist;
 CREATE INDEX IF NOT EXISTS ix_test_nodes_id_geom
     ON public.test_nodes USING gist
     (id, geom)
     WITH (fillfactor=90, buffering=auto);

 ANALYZE test_nodes;
 ANALYZE test_way_nodes;

 QUERY PLAN

 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
  Nested Loop  (cost=0.70..29.25 rows=1 width=8) (actual time=0.038..0.039
 rows=0 loops=1)
    ->  Index Scan using idx_test_way_nodes_node_id on test_way_nodes wn
 (cost=0.42..8.44 rows=1 width=16) (actual time=0.026..0.027 rows=1
 loops=1)
          Index Cond: (node_id = '12862767139'::bigint)
    ->  Index Scan using ix_test_nodes_id_geom on test_nodes n
 (cost=0.28..20.80 rows=1 width=8) (actual time=0.010..0.010 rows=0
 loops=1)
          Index Cond: ((id = '12862767139'::bigint) AND (geom @
 '0103000020E61000000100000005000000D5A35F11B27A184013A1116C5C4E4A40D5A35F11B27A18402A2F432D179A4A40D529EA27F75E1C402A2F432D179A4A40D529EA27F75E1C4013A1116C5C4E4A40D5A35F11B27A184013A1116C5C4E4A4
 0'::geometry))
          Filter:
 st_contains('0103000020E61000000100000005000000D5A35F11B27A184013A1116C5C4E4A40D5A35F11B27A18402A2F432D179A4A40D529EA27F75E1C402A2F432D179A4A40D529EA27F75E1C4013A1116C5C4E4A40D5A35F11B27A184013A1116C5C4E4A40'::geometry,
 geom)
  Planning Time: 0.261 ms
  Execution Time: 0.066 ms
 (8 rows)

 }}}

 I was surprised it favored the btree_gist index over the primary key
 index.  I'm going to try with the larger data set
-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/5984#comment:3>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.