New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken optimization for the stored dbkeys [CORE4038] #4368
Comments
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovstatus: Open [ 1 ] => In Progress [ 3 ] |
Modified by: @dyemanovreporter: Dmitry Yemanov [ dimitr ] => John Kilin [ johnkilin ] |
Modified by: @dyemanovstatus: In Progress [ 3 ] => Open [ 1 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5.3 [ 10461 ] |
Modified by: @pmakowskistatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovstatus: Closed [ 6 ] => Closed [ 6 ] |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Submitted by: John Kilin (johnkilin)
Is related to QA524
Test case:
create table t (dbkey char(8) character set octets);
create index it on t (dbkey);
select * from t as t1
left join t as t2 on t2.dbkey = t1.rdb$db_key
-- expected plan:
PLAN JOIN (T1 NATURAL, T2 INDEX (IT))
-- actual plan:
PLAN JOIN (T1 NATURAL, T2 NATURAL)
This is a regression introduced with CORE2550 when a separate internal datatype was created for dbkeys.
Commits: 2cab423 e0068e7 FirebirdSQL/fbt-repository@07cee52
====== Test Details ======
See also: CORE4492, CORE4530
The text was updated successfully, but these errors were encountered: