Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.6.0, 7.1.6, 7.2.3
-
Untriaged
-
0
-
Yes
Description
We do not allow using primary scan if it is inside a correlated subquery. However, if the primary index is used as a secondary index scan, previously we allow such plans. There are two situations where a primary index can be used as a secondary index scan:
- if the primary index is used in a covering index scan
- if the primary index is used with index spans (i.e. when there are predicates on meta().id)
Such usage is no longer permitted after the fix for MB-53565/MB-54045/MB-59552 (in Trinity, 7.2.0 and 7.1.6-MP1, respectively).
We need to restore previous behavior.
Repro:
CREATE PRIMARY INDEX ON default;
|
|
INSERT INTO default VALUES("k01", {"c1": 1, "c2": 1});
|
|
-- when used as covering index scan
|
SELECT RAW (SELECT 1 FROM default AS d WHERE META(d).id = META(t).id ) FROM default t;
|
|
-- when used as non-covering index scan but with index spans
|
SELECT RAW (SELECT d.c1 FROM default AS d WHERE META(d).id = META(t).id ) FROM default t;
|
Note that this currently works in Trinity due to the enhancement in Trinity to allow primary scan if the keyspace has <= 1000 documents, but we can easily modify the repro such that the keyspace has more than 1000 documents and it'll fail in Trinity as well.
This works before the fix for the above-mentioned MBs.