ST_Within Not using index

[postgispaul]

Hi, I've got this query and I can't figure what I'm doing wrong. It doesn't use the geo-index.

Versions:

"POSTGIS="2.3.2 r15302" GEOS="3.6.1-CAPI-1.10.1 r4317" PROJ="Rel. 4.9.1, 04 March 2015" GDAL="GDAL 2.1.3, released 2017/20/01 GDAL_DATA not found" LIBXML="2.7.8" LIBJSON="0.12" (core procs from "2.3.0 r15146" need upgrade) RASTER (raster procs from "2.3.0 r (...)"
"PostgreSQL 9.6.1, compiled by Visual C++ build 1800, 64-bit"

This happens on a full planet_osm_polygon table. Definition:

CREATE TABLE public.planet_osm_polygon
(
  osm_id bigint,
  ... snip a number of irrelevant columns ...
  way geometry(Geometry,3857)
)
WITH (
  OIDS=FALSE
);


CREATE INDEX planet_osm_polygon_index
  ON public.planet_osm_polygon
  USING gist
  (way);

CREATE INDEX planet_osm_polygon_pkey
  ON public.planet_osm_polygon
  USING btree
  (osm_id);

I've done an analyze planet_osm_polygon but still the query planner surprises me.

select s.way from planet_osm_polygon s
join planet_osm_polygon ap on (ST_Within(s.way,ap.way))
where ap.osm_id=123456

results in a pkey lookup followed by a bitmap index scan

Nested Loop  (cost=6339.51..360823.14 rows=88540 width=229)
  Output: s.way
  ->  Index Scan using planet_osm_polygon_pkey on public.planet_osm_polygon ap  (cost=0.57..2.79 rows=1 width=229)
        Output: ap.osm_id, ap.highway, ap.surface, ap.railway, ap.waterway, ap.tunnel, ap.bridge, ap.oneway, ap.access, ap.name, ap.z_order, ap.way_area, ap.area, ap.natural, ap.water, ap.admin_level, ap.boundary, ap.landuse, ap.amenity, ap.parking, ap.a (...)
        Index Cond: (ap.osm_id = 123456)
  ->  Bitmap Heap Scan on public.planet_osm_polygon s  (cost=6338.94..359934.96 rows=88540 width=229)
        Output: s.osm_id, s.highway, s.surface, s.railway, s.waterway, s.tunnel, s.bridge, s.oneway, s.access, s.name, s.z_order, s.way_area, s.area, s.natural, s.water, s.admin_level, s.boundary, s.landuse, s.amenity, s.parking, s.aeroway, s.military, s (...)
        Recheck Cond: (ap.way ~ s.way)
        Filter: _st_contains(ap.way, s.way)
        ->  Bitmap Index Scan on planet_osm_polygon_index  (cost=0.00..6316.81 rows=265621 width=0)
              Index Cond: (ap.way ~ s.way)

adding ap.way ~ s.way and to the join condition:

select s.way from planet_osm_polygon s
join planet_osm_polygon ap on (ap.way ~ s.way and ST_Within(s.way,ap.way))
where ap.osm_id=123456

results in a pkey lookup and a normal index-scan

Nested Loop  (cost=1.12..373.05 rows=89 width=229)
  Output: s.way
  ->  Index Scan using planet_osm_polygon_pkey on public.planet_osm_polygon ap  (cost=0.57..2.79 rows=1 width=229)
        Output: ap.osm_id, ap.highway, ap.surface, ap.railway, ap.waterway, ap.tunnel, ap.bridge, ap.oneway, ap.access, ap.name, ap.z_order, ap.way_area, ap.area, ap.natural, ap.water, ap.admin_level, ap.boundary, ap.landuse, ap.amenity, ap.parking, ap.a (...)
        Index Cond: (ap.osm_id = 123456)
  ->  Index Scan using planet_osm_polygon_index on public.planet_osm_polygon s  (cost=0.55..369.37 rows=89 width=229)
        Output: s.osm_id, s.highway, s.surface, s.railway, s.waterway, s.tunnel, s.bridge, s.oneway, s.access, s.name, s.z_order, s.way_area, s.area, s.natural, s.water, s.admin_level, s.boundary, s.landuse, s.amenity, s.parking, s.aeroway, s.military, s (...)
        Index Cond: ((ap.way ~ s.way) AND (ap.way ~ s.way))
        Filter: _st_contains(ap.way, s.way)

One thing stands out here: the duplicate index condition ap.way ~ s.way

My question is: why isn't it planning to use the normal index-scan without adding ap.way ~ s.way. After all, it is part of the st_within definition:

CREATE OR REPLACE FUNCTION public.st_within(
    geom1 geometry,
    geom2 geometry)
  RETURNS boolean AS
'SELECT $2 OPERATOR(public.~) $1 AND public._ST_Contains($2,$1)'
  LANGUAGE sql IMMUTABLE
  COST 100;