Handle mixed returnable and non-returnable columns better in IOS.
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 3 Jan 2022 21:12:11 +0000 (16:12 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 3 Jan 2022 21:12:11 +0000 (16:12 -0500)
We can revert the code changes of commit b5febc1d1 now, because
commit 9a3ddeb51 installed a real solution for the difficulty
that b5febc1d1 just dodged, namely that the planner might pick
the wrong one of several index columns nominally containing the
same value.  It only matters which one we pick if we pick one
that's not returnable, and that mistake is now foreclosed.

Although both of the aforementioned commits were back-patched,
I don't feel a need to take any risk by back-patching this one.
The cases that it improves are very corner-ish.

Discussion: https://postgr.es/m/3179992.1641150853@sss.pgh.pa.us

contrib/btree_gist/expected/inet.out
contrib/btree_gist/sql/inet.sql
src/backend/optimizer/path/indxpath.c

index c323d903da4613211998d24b2f3832c5c9c81f85..f15f1435f0ab2270e9c4c8f81288be8e2395d421 100644 (file)
@@ -83,13 +83,13 @@ SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;
 
 DROP INDEX inetidx;
 CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
--- likewise here (checks for core planner bug)
+-- this can be an index-only scan, as long as the planner uses the right column
 EXPLAIN (COSTS OFF)
 SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;
-                     QUERY PLAN                     
-----------------------------------------------------
+                       QUERY PLAN                        
+---------------------------------------------------------
  Aggregate
-   ->  Index Scan using inettmp_a_a1_idx on inettmp
+   ->  Index Only Scan using inettmp_a_a1_idx on inettmp
          Index Cond: (a = '89.225.196.191'::inet)
 (3 rows)
 
index 4b8d354b00ee5b255db0ef8a4e9f228592656a3f..249e8085c3b3b6487be8db2adab8bed89f894c85 100644 (file)
@@ -42,7 +42,7 @@ DROP INDEX inetidx;
 
 CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
 
--- likewise here (checks for core planner bug)
+-- this can be an index-only scan, as long as the planner uses the right column
 EXPLAIN (COSTS OFF)
 SELECT count(*) FROM inettmp WHERE a  = '89.225.196.191'::inet;
 
index 0e4e00eaf02cc8bf6559b5dc1ca37c379cf808f8..e2def356f6342f7c69bc366681e99d8afb04e373 100644 (file)
@@ -1807,7 +1807,6 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
    bool        result;
    Bitmapset  *attrs_used = NULL;
    Bitmapset  *index_canreturn_attrs = NULL;
-   Bitmapset  *index_cannotreturn_attrs = NULL;
    ListCell   *lc;
    int         i;
 
@@ -1847,11 +1846,7 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
 
    /*
     * Construct a bitmapset of columns that the index can return back in an
-    * index-only scan.  If there are multiple index columns containing the
-    * same attribute, all of them must be capable of returning the value,
-    * since we might recheck operators on any of them.  (Potentially we could
-    * be smarter about that, but it's such a weird situation that it doesn't
-    * seem worth spending a lot of sweat on.)
+    * index-only scan.
     */
    for (i = 0; i < index->ncolumns; i++)
    {
@@ -1868,21 +1863,13 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
            index_canreturn_attrs =
                bms_add_member(index_canreturn_attrs,
                               attno - FirstLowInvalidHeapAttributeNumber);
-       else
-           index_cannotreturn_attrs =
-               bms_add_member(index_cannotreturn_attrs,
-                              attno - FirstLowInvalidHeapAttributeNumber);
    }
 
-   index_canreturn_attrs = bms_del_members(index_canreturn_attrs,
-                                           index_cannotreturn_attrs);
-
    /* Do we have all the necessary attributes? */
    result = bms_is_subset(attrs_used, index_canreturn_attrs);
 
    bms_free(attrs_used);
    bms_free(index_canreturn_attrs);
-   bms_free(index_cannotreturn_attrs);
 
    return result;
 }