Skip to content

Commit 32e8016

Browse files
committed
Don't use_physical_tlist for an IOS with non-returnable columns.
createplan.c tries to save a runtime projection step by specifying a scan plan node's output as being exactly the table's columns, or index's columns in the case of an index-only scan, if there is not a reason to do otherwise. This logic did not previously pay attention to whether an index's columns are returnable. That worked, sort of accidentally, until commit 9a3ddeb taught setrefs.c to reject plans that try to read a non-returnable column. I have no desire to loosen setrefs.c's new check, so instead adjust use_physical_tlist() to not try to optimize this way when there are non-returnable column(s). Per report from Ryan Kelly. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/CAHUie24ddN+pDNw7fkhNrjrwAX=fXXfGZZEHhRuofV_N_ftaSg@mail.gmail.com
1 parent 61c20a5 commit 32e8016

File tree

3 files changed

+37
-0
lines changed

3 files changed

+37
-0
lines changed

src/backend/optimizer/plan/createplan.c

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -876,6 +876,22 @@ use_physical_tlist(PlannerInfo *root, Path *path, int flags)
876876
return false;
877877
}
878878

879+
/*
880+
* For an index-only scan, the "physical tlist" is the index's indextlist.
881+
* We can only return that without a projection if all the index's columns
882+
* are returnable.
883+
*/
884+
if (path->pathtype == T_IndexOnlyScan)
885+
{
886+
IndexOptInfo *indexinfo = ((IndexPath *) path)->indexinfo;
887+
888+
for (i = 0; i < indexinfo->ncolumns; i++)
889+
{
890+
if (!indexinfo->canreturn[i])
891+
return false;
892+
}
893+
}
894+
879895
/*
880896
* Also, can't do it if CP_LABEL_TLIST is specified and path is requested
881897
* to emit any sort/group columns that are not simple Vars. (If they are

src/test/regress/expected/gist.out

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -281,6 +281,22 @@ select p from gist_tbl where circle(p,1) @> circle(point(0,0),0.95);
281281
(0,0)
282282
(1 row)
283283

284+
-- Also check that use_physical_tlist doesn't trigger in such cases.
285+
explain (verbose, costs off)
286+
select count(*) from gist_tbl;
287+
QUERY PLAN
288+
---------------------------------------------------------------------
289+
Aggregate
290+
Output: count(*)
291+
-> Index Only Scan using gist_tbl_multi_index on public.gist_tbl
292+
(3 rows)
293+
294+
select count(*) from gist_tbl;
295+
count
296+
-------
297+
10001
298+
(1 row)
299+
284300
-- This case isn't supported, but it should at least EXPLAIN correctly.
285301
explain (verbose, costs off)
286302
select p from gist_tbl order by circle(p,1) <-> point(0,0) limit 1;

src/test/regress/sql/gist.sql

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -143,6 +143,11 @@ explain (verbose, costs off)
143143
select p from gist_tbl where circle(p,1) @> circle(point(0,0),0.95);
144144
select p from gist_tbl where circle(p,1) @> circle(point(0,0),0.95);
145145

146+
-- Also check that use_physical_tlist doesn't trigger in such cases.
147+
explain (verbose, costs off)
148+
select count(*) from gist_tbl;
149+
select count(*) from gist_tbl;
150+
146151
-- This case isn't supported, but it should at least EXPLAIN correctly.
147152
explain (verbose, costs off)
148153
select p from gist_tbl order by circle(p,1) <-> point(0,0) limit 1;

0 commit comments

Comments
 (0)