2014-11-19 18:24:58 +01:00
|
|
|
--
|
|
|
|
-- Test GiST indexes.
|
|
|
|
--
|
|
|
|
-- There are other tests to test different GiST opclasses. This is for
|
|
|
|
-- testing GiST code itself. Vacuuming in particular.
|
|
|
|
create table gist_point_tbl(id int4, p point);
|
|
|
|
create index gist_pointidx on gist_point_tbl using gist(p);
|
2017-10-19 14:14:18 +02:00
|
|
|
-- Verify the fillfactor and buffering options
|
|
|
|
create index gist_pointidx2 on gist_point_tbl using gist(p) with (buffering = on, fillfactor=50);
|
|
|
|
create index gist_pointidx3 on gist_point_tbl using gist(p) with (buffering = off);
|
|
|
|
create index gist_pointidx4 on gist_point_tbl using gist(p) with (buffering = auto);
|
|
|
|
drop index gist_pointidx2, gist_pointidx3, gist_pointidx4;
|
|
|
|
-- Make sure bad values are refused
|
|
|
|
create index gist_pointidx5 on gist_point_tbl using gist(p) with (buffering = invalid_value);
|
2019-09-25 20:56:52 +02:00
|
|
|
ERROR: invalid value for enum option "buffering": invalid_value
|
2017-10-19 14:14:18 +02:00
|
|
|
DETAIL: Valid values are "on", "off", and "auto".
|
|
|
|
create index gist_pointidx5 on gist_point_tbl using gist(p) with (fillfactor=9);
|
|
|
|
ERROR: value 9 out of bounds for option "fillfactor"
|
|
|
|
DETAIL: Valid values are between "10" and "100".
|
|
|
|
create index gist_pointidx5 on gist_point_tbl using gist(p) with (fillfactor=101);
|
|
|
|
ERROR: value 101 out of bounds for option "fillfactor"
|
|
|
|
DETAIL: Valid values are between "10" and "100".
|
2014-11-19 18:24:58 +01:00
|
|
|
-- Insert enough data to create a tree that's a couple of levels deep.
|
|
|
|
insert into gist_point_tbl (id, p)
|
|
|
|
select g, point(g*10, g*10) from generate_series(1, 10000) g;
|
|
|
|
insert into gist_point_tbl (id, p)
|
|
|
|
select g+100000, point(g*10+1, g*10+1) from generate_series(1, 10000) g;
|
|
|
|
-- To test vacuum, delete some entries from all over the index.
|
|
|
|
delete from gist_point_tbl where id % 2 = 1;
|
2019-03-22 12:21:20 +01:00
|
|
|
-- And also delete some concentration of values.
|
|
|
|
delete from gist_point_tbl where id > 5000;
|
2015-06-04 22:42:23 +02:00
|
|
|
vacuum analyze gist_point_tbl;
|
2017-10-19 14:14:18 +02:00
|
|
|
-- rebuild the index with a different fillfactor
|
|
|
|
alter index gist_pointidx SET (fillfactor = 40);
|
|
|
|
reindex index gist_pointidx;
|
2015-03-26 18:12:00 +01:00
|
|
|
--
|
|
|
|
-- Test Index-only plans on GiST indexes
|
|
|
|
--
|
2022-04-25 15:00:49 +02:00
|
|
|
create unlogged table gist_tbl (b box, p point, c circle);
|
2015-03-26 18:12:00 +01:00
|
|
|
insert into gist_tbl
|
|
|
|
select box(point(0.05*i, 0.05*i), point(0.05*i, 0.05*i)),
|
|
|
|
point(0.05*i, 0.05*i),
|
|
|
|
circle(point(0.05*i, 0.05*i), 1.0)
|
|
|
|
from generate_series(0,10000) as i;
|
2015-06-04 22:42:23 +02:00
|
|
|
vacuum analyze gist_tbl;
|
2015-03-26 18:12:00 +01:00
|
|
|
set enable_seqscan=off;
|
|
|
|
set enable_bitmapscan=off;
|
|
|
|
set enable_indexonlyscan=on;
|
|
|
|
-- Test index-only scan with point opclass
|
|
|
|
create index gist_tbl_point_index on gist_tbl using gist (p);
|
|
|
|
-- check that the planner chooses an index-only scan
|
|
|
|
explain (costs off)
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5));
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_point_index on gist_tbl
|
|
|
|
Index Cond: (p <@ '(0.5,0.5),(0,0)'::box)
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- execute the same
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5));
|
|
|
|
p
|
|
|
|
-------------
|
|
|
|
(0,0)
|
|
|
|
(0.05,0.05)
|
|
|
|
(0.1,0.1)
|
|
|
|
(0.15,0.15)
|
|
|
|
(0.2,0.2)
|
|
|
|
(0.25,0.25)
|
|
|
|
(0.3,0.3)
|
|
|
|
(0.35,0.35)
|
|
|
|
(0.4,0.4)
|
|
|
|
(0.45,0.45)
|
|
|
|
(0.5,0.5)
|
|
|
|
(11 rows)
|
|
|
|
|
|
|
|
-- Also test an index-only knn-search
|
|
|
|
explain (costs off)
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
|
2015-08-25 17:43:37 +02:00
|
|
|
order by p <-> point(0.201, 0.201);
|
2015-03-26 18:12:00 +01:00
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_point_index on gist_tbl
|
|
|
|
Index Cond: (p <@ '(0.5,0.5),(0,0)'::box)
|
2015-08-25 17:43:37 +02:00
|
|
|
Order By: (p <-> '(0.201,0.201)'::point)
|
2015-03-26 18:12:00 +01:00
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
|
2015-08-25 17:43:37 +02:00
|
|
|
order by p <-> point(0.201, 0.201);
|
2015-03-26 18:12:00 +01:00
|
|
|
p
|
|
|
|
-------------
|
|
|
|
(0.2,0.2)
|
|
|
|
(0.25,0.25)
|
|
|
|
(0.15,0.15)
|
|
|
|
(0.3,0.3)
|
|
|
|
(0.1,0.1)
|
|
|
|
(0.35,0.35)
|
|
|
|
(0.05,0.05)
|
|
|
|
(0.4,0.4)
|
2015-08-25 17:43:37 +02:00
|
|
|
(0,0)
|
2015-03-26 18:12:00 +01:00
|
|
|
(0.45,0.45)
|
|
|
|
(0.5,0.5)
|
|
|
|
(11 rows)
|
|
|
|
|
2015-05-22 01:47:48 +02:00
|
|
|
-- Check commuted case as well
|
|
|
|
explain (costs off)
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
|
2015-08-25 17:43:37 +02:00
|
|
|
order by point(0.101, 0.101) <-> p;
|
2015-05-22 01:47:48 +02:00
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_point_index on gist_tbl
|
|
|
|
Index Cond: (p <@ '(0.5,0.5),(0,0)'::box)
|
2015-08-25 17:43:37 +02:00
|
|
|
Order By: (p <-> '(0.101,0.101)'::point)
|
2015-05-22 01:47:48 +02:00
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select p from gist_tbl where p <@ box(point(0,0), point(0.5, 0.5))
|
2015-08-25 17:43:37 +02:00
|
|
|
order by point(0.101, 0.101) <-> p;
|
2015-05-22 01:47:48 +02:00
|
|
|
p
|
|
|
|
-------------
|
|
|
|
(0.1,0.1)
|
|
|
|
(0.15,0.15)
|
|
|
|
(0.05,0.05)
|
|
|
|
(0.2,0.2)
|
2015-08-25 17:43:37 +02:00
|
|
|
(0,0)
|
2015-05-22 01:47:48 +02:00
|
|
|
(0.25,0.25)
|
|
|
|
(0.3,0.3)
|
|
|
|
(0.35,0.35)
|
|
|
|
(0.4,0.4)
|
|
|
|
(0.45,0.45)
|
|
|
|
(0.5,0.5)
|
|
|
|
(11 rows)
|
|
|
|
|
Fix pfree-of-already-freed-tuple when rescanning a GiST index-only scan.
GiST's getNextNearest() function attempts to pfree the previously-returned
tuple if any (that is, scan->xs_hitup in HEAD, or scan->xs_itup in older
branches). However, if we are rescanning a plan node after ending a
previous scan early, those tuple pointers could be pointing to garbage,
because they would be pointing into the scan's pageDataCxt or queueCxt
which has been reset. In a debug build this reliably results in a crash,
although I think it might sometimes accidentally fail to fail in
production builds.
To fix, clear the pointer field anyplace we reset a context it might
be pointing into. This may be overkill --- I think probably only the
queueCxt case is involved in this bug, so that resetting in gistrescan()
would be sufficient --- but dangling pointers are generally bad news,
so let's avoid them.
Another plausible answer might be to just not bother with the pfree in
getNextNearest(). The reconstructed tuples would go away anyway in the
context resets, and I'm far from convinced that freeing them a bit earlier
really saves anything meaningful. I'll stick with the original logic in
this patch, but if we find more problems in the same area we should
consider that approach.
Per bug #14641 from Denis Smirnov. Back-patch to 9.5 where this
logic was introduced.
Discussion: https://postgr.es/m/20170504072034.24366.57688@wrigleys.postgresql.org
2017-05-04 19:59:13 +02:00
|
|
|
-- Check case with multiple rescans (bug #14641)
|
|
|
|
explain (costs off)
|
|
|
|
select p from
|
|
|
|
(values (box(point(0,0), point(0.5,0.5))),
|
|
|
|
(box(point(0.5,0.5), point(0.75,0.75))),
|
|
|
|
(box(point(0.8,0.8), point(1.0,1.0)))) as v(bb)
|
|
|
|
cross join lateral
|
|
|
|
(select p from gist_tbl where p <@ bb order by p <-> bb[0] limit 2) ss;
|
|
|
|
QUERY PLAN
|
|
|
|
--------------------------------------------------------------------
|
|
|
|
Nested Loop
|
|
|
|
-> Values Scan on "*VALUES*"
|
|
|
|
-> Limit
|
|
|
|
-> Index Only Scan using gist_tbl_point_index on gist_tbl
|
|
|
|
Index Cond: (p <@ "*VALUES*".column1)
|
|
|
|
Order By: (p <-> ("*VALUES*".column1)[0])
|
|
|
|
(6 rows)
|
|
|
|
|
|
|
|
select p from
|
|
|
|
(values (box(point(0,0), point(0.5,0.5))),
|
|
|
|
(box(point(0.5,0.5), point(0.75,0.75))),
|
|
|
|
(box(point(0.8,0.8), point(1.0,1.0)))) as v(bb)
|
|
|
|
cross join lateral
|
|
|
|
(select p from gist_tbl where p <@ bb order by p <-> bb[0] limit 2) ss;
|
|
|
|
p
|
|
|
|
-------------
|
|
|
|
(0.5,0.5)
|
|
|
|
(0.45,0.45)
|
|
|
|
(0.75,0.75)
|
|
|
|
(0.7,0.7)
|
|
|
|
(1,1)
|
|
|
|
(0.95,0.95)
|
|
|
|
(6 rows)
|
|
|
|
|
2015-03-26 18:12:00 +01:00
|
|
|
drop index gist_tbl_point_index;
|
|
|
|
-- Test index-only scan with box opclass
|
|
|
|
create index gist_tbl_box_index on gist_tbl using gist (b);
|
|
|
|
-- check that the planner chooses an index-only scan
|
|
|
|
explain (costs off)
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6));
|
|
|
|
QUERY PLAN
|
|
|
|
------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_box_index on gist_tbl
|
|
|
|
Index Cond: (b <@ '(6,6),(5,5)'::box)
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- execute the same
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6));
|
|
|
|
b
|
|
|
|
-------------------------
|
|
|
|
(5,5),(5,5)
|
|
|
|
(5.05,5.05),(5.05,5.05)
|
|
|
|
(5.1,5.1),(5.1,5.1)
|
|
|
|
(5.15,5.15),(5.15,5.15)
|
|
|
|
(5.2,5.2),(5.2,5.2)
|
|
|
|
(5.25,5.25),(5.25,5.25)
|
|
|
|
(5.3,5.3),(5.3,5.3)
|
|
|
|
(5.35,5.35),(5.35,5.35)
|
|
|
|
(5.4,5.4),(5.4,5.4)
|
|
|
|
(5.45,5.45),(5.45,5.45)
|
|
|
|
(5.5,5.5),(5.5,5.5)
|
|
|
|
(5.55,5.55),(5.55,5.55)
|
|
|
|
(5.6,5.6),(5.6,5.6)
|
|
|
|
(5.65,5.65),(5.65,5.65)
|
|
|
|
(5.7,5.7),(5.7,5.7)
|
|
|
|
(5.75,5.75),(5.75,5.75)
|
|
|
|
(5.8,5.8),(5.8,5.8)
|
|
|
|
(5.85,5.85),(5.85,5.85)
|
|
|
|
(5.9,5.9),(5.9,5.9)
|
|
|
|
(5.95,5.95),(5.95,5.95)
|
|
|
|
(6,6),(6,6)
|
|
|
|
(21 rows)
|
|
|
|
|
2019-07-14 13:56:18 +02:00
|
|
|
-- Also test an index-only knn-search
|
|
|
|
explain (costs off)
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6))
|
|
|
|
order by b <-> point(5.2, 5.91);
|
|
|
|
QUERY PLAN
|
|
|
|
------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_box_index on gist_tbl
|
|
|
|
Index Cond: (b <@ '(6,6),(5,5)'::box)
|
|
|
|
Order By: (b <-> '(5.2,5.91)'::point)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6))
|
|
|
|
order by b <-> point(5.2, 5.91);
|
|
|
|
b
|
|
|
|
-------------------------
|
|
|
|
(5.55,5.55),(5.55,5.55)
|
|
|
|
(5.6,5.6),(5.6,5.6)
|
|
|
|
(5.5,5.5),(5.5,5.5)
|
|
|
|
(5.65,5.65),(5.65,5.65)
|
|
|
|
(5.45,5.45),(5.45,5.45)
|
|
|
|
(5.7,5.7),(5.7,5.7)
|
|
|
|
(5.4,5.4),(5.4,5.4)
|
|
|
|
(5.75,5.75),(5.75,5.75)
|
|
|
|
(5.35,5.35),(5.35,5.35)
|
|
|
|
(5.8,5.8),(5.8,5.8)
|
|
|
|
(5.3,5.3),(5.3,5.3)
|
|
|
|
(5.85,5.85),(5.85,5.85)
|
|
|
|
(5.25,5.25),(5.25,5.25)
|
|
|
|
(5.9,5.9),(5.9,5.9)
|
|
|
|
(5.2,5.2),(5.2,5.2)
|
|
|
|
(5.95,5.95),(5.95,5.95)
|
|
|
|
(5.15,5.15),(5.15,5.15)
|
|
|
|
(6,6),(6,6)
|
|
|
|
(5.1,5.1),(5.1,5.1)
|
|
|
|
(5.05,5.05),(5.05,5.05)
|
|
|
|
(5,5),(5,5)
|
|
|
|
(21 rows)
|
|
|
|
|
|
|
|
-- Check commuted case as well
|
|
|
|
explain (costs off)
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6))
|
|
|
|
order by point(5.2, 5.91) <-> b;
|
|
|
|
QUERY PLAN
|
|
|
|
------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_box_index on gist_tbl
|
|
|
|
Index Cond: (b <@ '(6,6),(5,5)'::box)
|
|
|
|
Order By: (b <-> '(5.2,5.91)'::point)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select b from gist_tbl where b <@ box(point(5,5), point(6,6))
|
|
|
|
order by point(5.2, 5.91) <-> b;
|
|
|
|
b
|
|
|
|
-------------------------
|
|
|
|
(5.55,5.55),(5.55,5.55)
|
|
|
|
(5.6,5.6),(5.6,5.6)
|
|
|
|
(5.5,5.5),(5.5,5.5)
|
|
|
|
(5.65,5.65),(5.65,5.65)
|
|
|
|
(5.45,5.45),(5.45,5.45)
|
|
|
|
(5.7,5.7),(5.7,5.7)
|
|
|
|
(5.4,5.4),(5.4,5.4)
|
|
|
|
(5.75,5.75),(5.75,5.75)
|
|
|
|
(5.35,5.35),(5.35,5.35)
|
|
|
|
(5.8,5.8),(5.8,5.8)
|
|
|
|
(5.3,5.3),(5.3,5.3)
|
|
|
|
(5.85,5.85),(5.85,5.85)
|
|
|
|
(5.25,5.25),(5.25,5.25)
|
|
|
|
(5.9,5.9),(5.9,5.9)
|
|
|
|
(5.2,5.2),(5.2,5.2)
|
|
|
|
(5.95,5.95),(5.95,5.95)
|
|
|
|
(5.15,5.15),(5.15,5.15)
|
|
|
|
(6,6),(6,6)
|
|
|
|
(5.1,5.1),(5.1,5.1)
|
|
|
|
(5.05,5.05),(5.05,5.05)
|
|
|
|
(5,5),(5,5)
|
|
|
|
(21 rows)
|
|
|
|
|
2015-03-26 18:12:00 +01:00
|
|
|
drop index gist_tbl_box_index;
|
|
|
|
-- Test that an index-only scan is not chosen, when the query involves the
|
|
|
|
-- circle column (the circle opclass does not support index-only scans).
|
|
|
|
create index gist_tbl_multi_index on gist_tbl using gist (p, c);
|
|
|
|
explain (costs off)
|
|
|
|
select p, c from gist_tbl
|
|
|
|
where p <@ box(point(5,5), point(6, 6));
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------
|
|
|
|
Index Scan using gist_tbl_multi_index on gist_tbl
|
|
|
|
Index Cond: (p <@ '(6,6),(5,5)'::box)
|
|
|
|
(2 rows)
|
|
|
|
|
|
|
|
-- execute the same
|
|
|
|
select b, p from gist_tbl
|
|
|
|
where b <@ box(point(4.5, 4.5), point(5.5, 5.5))
|
|
|
|
and p <@ box(point(5,5), point(6, 6));
|
|
|
|
b | p
|
|
|
|
-------------------------+-------------
|
|
|
|
(5,5),(5,5) | (5,5)
|
|
|
|
(5.05,5.05),(5.05,5.05) | (5.05,5.05)
|
|
|
|
(5.1,5.1),(5.1,5.1) | (5.1,5.1)
|
|
|
|
(5.15,5.15),(5.15,5.15) | (5.15,5.15)
|
|
|
|
(5.2,5.2),(5.2,5.2) | (5.2,5.2)
|
|
|
|
(5.25,5.25),(5.25,5.25) | (5.25,5.25)
|
|
|
|
(5.3,5.3),(5.3,5.3) | (5.3,5.3)
|
|
|
|
(5.35,5.35),(5.35,5.35) | (5.35,5.35)
|
|
|
|
(5.4,5.4),(5.4,5.4) | (5.4,5.4)
|
|
|
|
(5.45,5.45),(5.45,5.45) | (5.45,5.45)
|
|
|
|
(5.5,5.5),(5.5,5.5) | (5.5,5.5)
|
|
|
|
(11 rows)
|
|
|
|
|
|
|
|
drop index gist_tbl_multi_index;
|
Fix index-only scan plans when not all index columns can be returned.
If an index has both returnable and non-returnable columns, and one of
the non-returnable columns is an expression using a Var that is in a
returnable column, then a query returning that expression could result
in an index-only scan plan that attempts to read the non-returnable
column, instead of recomputing the expression from the returnable
column as intended.
To fix, redefine the "indextlist" list of an IndexOnlyScan plan node
as containing null Consts in place of any non-returnable columns.
This solves the problem by preventing setrefs.c from falsely matching
to such entries. The executor is happy since it only cares about the
exposed types of the entries, and ruleutils.c doesn't care because a
correct plan won't reference those entries. I considered some other
ways to prevent setrefs.c from doing the wrong thing, but this way
seems good since (a) it allows a very localized fix, (b) it makes
the indextlist structure more compact in many cases, and (c) the
indextlist is now a more faithful representation of what the index AM
will actually produce, viz. nulls for any non-returnable columns.
This is easier to hit since we introduced included columns, but it's
possible to construct failing examples without that, as per the
added regression test. Hence, back-patch to all supported branches.
Per bug #17350 from Louis Jachiet.
Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
2022-01-01 22:12:03 +01:00
|
|
|
-- Test that we don't try to return the value of a non-returnable
|
|
|
|
-- column in an index-only scan. (This isn't GIST-specific, but
|
|
|
|
-- it only applies to index AMs that can return some columns and not
|
|
|
|
-- others, so GIST with appropriate opclasses is a convenient test case.)
|
|
|
|
create index gist_tbl_multi_index on gist_tbl using gist (circle(p,1), p);
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select circle(p,1) from gist_tbl
|
|
|
|
where p <@ box(point(5, 5), point(5.3, 5.3));
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_multi_index on public.gist_tbl
|
|
|
|
Output: circle(p, '1'::double precision)
|
|
|
|
Index Cond: (gist_tbl.p <@ '(5.3,5.3),(5,5)'::box)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select circle(p,1) from gist_tbl
|
|
|
|
where p <@ box(point(5, 5), point(5.3, 5.3));
|
|
|
|
circle
|
|
|
|
-----------------
|
|
|
|
<(5,5),1>
|
|
|
|
<(5.05,5.05),1>
|
|
|
|
<(5.1,5.1),1>
|
|
|
|
<(5.15,5.15),1>
|
|
|
|
<(5.2,5.2),1>
|
|
|
|
<(5.25,5.25),1>
|
|
|
|
<(5.3,5.3),1>
|
|
|
|
(7 rows)
|
|
|
|
|
Fix index-only scan plans, take 2.
Commit 4ace45677 failed to fix the problem fully, because the
same issue of attempting to fetch a non-returnable index column
can occur when rechecking the indexqual after using a lossy index
operator. Moreover, it broke EXPLAIN for such indexquals (which
indicates a gap in our test cases :-().
Revert the code changes of 4ace45677 in favor of adding a new field
to struct IndexOnlyScan, containing a version of the indexqual that
can be executed against the index-returned tuple without using any
non-returnable columns. (The restrictions imposed by check_index_only
guarantee this is possible, although we may have to recompute indexed
expressions.) Support construction of that during setrefs.c
processing by marking IndexOnlyScan.indextlist entries as resjunk
if they can't be returned, rather than removing them entirely.
(We could alternatively require setrefs.c to look up the IndexOptInfo
again, but abusing resjunk this way seems like a reasonably safe way
to avoid needing to do that.)
This solution isn't great from an API-stability standpoint: if there
are any extensions out there that build IndexOnlyScan structs directly,
they'll be broken in the next minor releases. However, only a very
invasive extension would be likely to do such a thing. There's no
change in the Path representation, so typical planner extensions
shouldn't have a problem.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/3179992.1641150853@sss.pgh.pa.us
Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
2022-01-03 21:42:27 +01:00
|
|
|
-- Similarly, test that index rechecks involving a non-returnable column
|
|
|
|
-- are done correctly.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select p from gist_tbl where circle(p,1) @> circle(point(0,0),0.95);
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------------------------------------------
|
|
|
|
Index Only Scan using gist_tbl_multi_index on public.gist_tbl
|
|
|
|
Output: p
|
|
|
|
Index Cond: ((circle(gist_tbl.p, '1'::double precision)) @> '<(0,0),0.95>'::circle)
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select p from gist_tbl where circle(p,1) @> circle(point(0,0),0.95);
|
|
|
|
p
|
|
|
|
-------
|
|
|
|
(0,0)
|
|
|
|
(1 row)
|
|
|
|
|
2022-02-11 21:23:52 +01:00
|
|
|
-- Also check that use_physical_tlist doesn't trigger in such cases.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select count(*) from gist_tbl;
|
|
|
|
QUERY PLAN
|
|
|
|
---------------------------------------------------------------------
|
|
|
|
Aggregate
|
|
|
|
Output: count(*)
|
|
|
|
-> Index Only Scan using gist_tbl_multi_index on public.gist_tbl
|
|
|
|
(3 rows)
|
|
|
|
|
|
|
|
select count(*) from gist_tbl;
|
|
|
|
count
|
|
|
|
-------
|
|
|
|
10001
|
|
|
|
(1 row)
|
|
|
|
|
Fix index-only scan plans, take 2.
Commit 4ace45677 failed to fix the problem fully, because the
same issue of attempting to fetch a non-returnable index column
can occur when rechecking the indexqual after using a lossy index
operator. Moreover, it broke EXPLAIN for such indexquals (which
indicates a gap in our test cases :-().
Revert the code changes of 4ace45677 in favor of adding a new field
to struct IndexOnlyScan, containing a version of the indexqual that
can be executed against the index-returned tuple without using any
non-returnable columns. (The restrictions imposed by check_index_only
guarantee this is possible, although we may have to recompute indexed
expressions.) Support construction of that during setrefs.c
processing by marking IndexOnlyScan.indextlist entries as resjunk
if they can't be returned, rather than removing them entirely.
(We could alternatively require setrefs.c to look up the IndexOptInfo
again, but abusing resjunk this way seems like a reasonably safe way
to avoid needing to do that.)
This solution isn't great from an API-stability standpoint: if there
are any extensions out there that build IndexOnlyScan structs directly,
they'll be broken in the next minor releases. However, only a very
invasive extension would be likely to do such a thing. There's no
change in the Path representation, so typical planner extensions
shouldn't have a problem.
As before, back-patch to all supported branches.
Discussion: https://postgr.es/m/3179992.1641150853@sss.pgh.pa.us
Discussion: https://postgr.es/m/17350-b5bdcf476e5badbb@postgresql.org
2022-01-03 21:42:27 +01:00
|
|
|
-- This case isn't supported, but it should at least EXPLAIN correctly.
|
|
|
|
explain (verbose, costs off)
|
|
|
|
select p from gist_tbl order by circle(p,1) <-> point(0,0) limit 1;
|
|
|
|
QUERY PLAN
|
|
|
|
------------------------------------------------------------------------------------
|
|
|
|
Limit
|
|
|
|
Output: p, ((circle(p, '1'::double precision) <-> '(0,0)'::point))
|
|
|
|
-> Index Only Scan using gist_tbl_multi_index on public.gist_tbl
|
|
|
|
Output: p, (circle(p, '1'::double precision) <-> '(0,0)'::point)
|
|
|
|
Order By: ((circle(gist_tbl.p, '1'::double precision)) <-> '(0,0)'::point)
|
|
|
|
(5 rows)
|
|
|
|
|
|
|
|
select p from gist_tbl order by circle(p,1) <-> point(0,0) limit 1;
|
|
|
|
ERROR: lossy distance functions are not supported in index-only scans
|
2022-07-30 22:22:24 +02:00
|
|
|
-- Force an index build using buffering.
|
|
|
|
create index gist_tbl_box_index_forcing_buffering on gist_tbl using gist (p)
|
|
|
|
with (buffering=on, fillfactor=50);
|
2015-03-26 18:12:00 +01:00
|
|
|
-- Clean up
|
|
|
|
reset enable_seqscan;
|
|
|
|
reset enable_bitmapscan;
|
|
|
|
reset enable_indexonlyscan;
|
|
|
|
drop table gist_tbl;
|