You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class)
-- Good plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7))
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class
or r.rdb$default_class = sc.rdb$security_class)
-- Bad plan:
-- PLAN JOIN (R NATURAL, SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
An attempt to specify the expected plan manually throws an error:
-- index RDB$INDEX_7 cannot be used in the specified plan
A prerequisite is that the slave index must be unique.
One more example is below. In fact, this is a bit different issue, although related and thus can be described by the same ticket.
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class and r.rdb$relation_id = 0)
or (r.rdb$default_class = sc.rdb$security_class and r.rdb$relation_id = 1)
-- Reported (bad) plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
This time the prerequisite is that the OR predicate has two ANDed sub-conditions and one of them (filter) is indexable for the master table.
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class)
-- Good plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7))
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class
or r.rdb$default_class = sc.rdb$security_class)
-- Bad plan:
-- PLAN JOIN (R NATURAL, SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
An attempt to specify the expected plan manually throws an error:
-- index RDB$INDEX_7 cannot be used in the specified plan
A prerequisite is that the slave index must be unique.
=>
Test case:
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class)
-- Good plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7))
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class
or r.rdb$default_class = sc.rdb$security_class)
-- Bad plan:
-- PLAN JOIN (R NATURAL, SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
An attempt to specify the expected plan manually throws an error:
-- index RDB$INDEX_7 cannot be used in the specified plan
A prerequisite is that the slave index must be unique.
One more example is below. In fact, this is a bit different issue, although related and thus can be described by the same ticket.
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class and r.rdb$relation_id = 0)
or (r.rdb$default_class = sc.rdb$security_class and r.rdb$relation_id = 1)
-- Reported (bad) plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
This time the prerequisite is that the OR predicate has two ANDed sub-conditions and one of them (filter) is indexable for the master table.
Submitted by: @pavel-zotov
Is related to QA454
Test case:
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class)
-- Good plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7))
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class
or r.rdb$default_class = sc.rdb$security_class)
-- Bad plan:
-- PLAN JOIN (R NATURAL, SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R NATURAL, SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
An attempt to specify the expected plan manually throws an error:
-- index RDB$INDEX_7 cannot be used in the specified plan
A prerequisite is that the slave index must be unique.
One more example is below. In fact, this is a bit different issue, although related and thus can be described by the same ticket.
select *
from rdb$relations r
join rdb$security_classes sc
on (r.rdb$security_class = sc.rdb$security_class and r.rdb$relation_id = 0)
or (r.rdb$default_class = sc.rdb$security_class and r.rdb$relation_id = 1)
-- Reported (bad) plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC NATURAL)
-- Expected plan:
-- PLAN JOIN (R INDEX (RDB$INDEX_1, RDB$INDEX_1), SC INDEX (RDB$INDEX_7, RDB$INDEX_7))
This time the prerequisite is that the OR predicate has two ANDed sub-conditions and one of them (filter) is indexable for the master table.
Commits: 6e6d341 e0648e8 0005a71 FirebirdSQL/fbt-repository@cdc627b
The text was updated successfully, but these errors were encountered: