While working on the KNNGIST documentation I noticed that it's possible
to create queries that will try to use a KNN scan as the inside of a
mergejoin, leading to a failure because GIST hasn't got mark/restore
support. For example, in the current HEAD regression database:
regression=# set enable_seqscan TO 0;
SET
regression=# explain select * from point_tbl a, point_tbl b where (a.f1 <-> '(0,0)') = (b.f1 <-> '(0,0)') order by
(a.f1<-> '(0,0)'); QUERY PLAN
------------------------------------------------------------------------------------Merge Join (cost=0.00..16.94
rows=7width=32) Merge Cond: ((a.f1 <-> '(0,0)'::point) = (b.f1 <-> '(0,0)'::point)) -> Index Scan using gpointind on
point_tbla (cost=0.00..8.37 rows=7 width=16) Order By: (f1 <-> '(0,0)'::point) -> Index Scan using gpointind
onpoint_tbl b (cost=0.00..8.37 rows=7 width=16) Order By: (f1 <-> '(0,0)'::point)
(6 rows)
regression=# select * from point_tbl a, point_tbl b where (a.f1 <-> '(0,0)') = (b.f1 <-> '(0,0)') order by (a.f1 <->
'(0,0)');
ERROR: GiST does not support mark/restore
The current planner code will not consider a KNN scan unless it
matches the query's ORDER BY, so the ORDER BY in the above example is
required to provoke the failure.
This seems like a sufficiently far-fetched example that I'm not too
concerned about it. Adding mark/restore to GiST KNN scans doesn't look
practical at all; so if we were to try to do something, it would need to
involve hacking the planner to know that this plan type doesn't work,
which seems possible but klugy.
regards, tom lane