Skip to content

Commit 8a2e323

Browse files
committed
Handle mixed returnable and non-returnable columns better in IOS.
We can revert the code changes of commit b5febc1 now, because commit 9a3ddeb installed a real solution for the difficulty that b5febc1 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
1 parent 9a3ddeb commit 8a2e323

File tree

3 files changed

+6
-19
lines changed

3 files changed

+6
-19
lines changed

contrib/btree_gist/expected/inet.out

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -83,13 +83,13 @@ SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
8383

8484
DROP INDEX inetidx;
8585
CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
86-
-- likewise here (checks for core planner bug)
86+
-- this can be an index-only scan, as long as the planner uses the right column
8787
EXPLAIN (COSTS OFF)
8888
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
89-
QUERY PLAN
90-
----------------------------------------------------
89+
QUERY PLAN
90+
---------------------------------------------------------
9191
Aggregate
92-
-> Index Scan using inettmp_a_a1_idx on inettmp
92+
-> Index Only Scan using inettmp_a_a1_idx on inettmp
9393
Index Cond: (a = '89.225.196.191'::inet)
9494
(3 rows)
9595

contrib/btree_gist/sql/inet.sql

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,7 @@ DROP INDEX inetidx;
4242

4343
CREATE INDEX ON inettmp USING gist (a gist_inet_ops, a inet_ops);
4444

45-
-- likewise here (checks for core planner bug)
45+
-- this can be an index-only scan, as long as the planner uses the right column
4646
EXPLAIN (COSTS OFF)
4747
SELECT count(*) FROM inettmp WHERE a = '89.225.196.191'::inet;
4848

src/backend/optimizer/path/indxpath.c

Lines changed: 1 addition & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1807,7 +1807,6 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
18071807
bool result;
18081808
Bitmapset *attrs_used = NULL;
18091809
Bitmapset *index_canreturn_attrs = NULL;
1810-
Bitmapset *index_cannotreturn_attrs = NULL;
18111810
ListCell *lc;
18121811
int i;
18131812

@@ -1847,11 +1846,7 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
18471846

18481847
/*
18491848
* Construct a bitmapset of columns that the index can return back in an
1850-
* index-only scan. If there are multiple index columns containing the
1851-
* same attribute, all of them must be capable of returning the value,
1852-
* since we might recheck operators on any of them. (Potentially we could
1853-
* be smarter about that, but it's such a weird situation that it doesn't
1854-
* seem worth spending a lot of sweat on.)
1849+
* index-only scan.
18551850
*/
18561851
for (i = 0; i < index->ncolumns; i++)
18571852
{
@@ -1868,21 +1863,13 @@ check_index_only(RelOptInfo *rel, IndexOptInfo *index)
18681863
index_canreturn_attrs =
18691864
bms_add_member(index_canreturn_attrs,
18701865
attno - FirstLowInvalidHeapAttributeNumber);
1871-
else
1872-
index_cannotreturn_attrs =
1873-
bms_add_member(index_cannotreturn_attrs,
1874-
attno - FirstLowInvalidHeapAttributeNumber);
18751866
}
18761867

1877-
index_canreturn_attrs = bms_del_members(index_canreturn_attrs,
1878-
index_cannotreturn_attrs);
1879-
18801868
/* Do we have all the necessary attributes? */
18811869
result = bms_is_subset(attrs_used, index_canreturn_attrs);
18821870

18831871
bms_free(attrs_used);
18841872
bms_free(index_canreturn_attrs);
1885-
bms_free(index_cannotreturn_attrs);
18861873

18871874
return result;
18881875
}

0 commit comments

Comments
 (0)