Skip to content
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

subselect losing the index when where clause includes coalesce() [CORE4640] #4954

Closed
firebird-automations opened this issue Dec 17, 2014 · 10 comments

Comments

@firebird-automations
Copy link
Collaborator

firebird-automations commented Dec 17, 2014

Submitted by: Omacht András (aomacht)

Attachments:
FB_TEST.ZIP

See the attached database.

When running

select t3.id,
       (select first 1 v1.id
          from v1
          where v1.vc1 = 'A' and v1.i2 = 1000 and v1.i1 = coalesce(t3.i1_1, t3.i1_2))
  from t3

no indicies were found for view V1:

Plan
PLAN (V1 T1 NATURAL)
PLAN (V1 T2 NATURAL)
PLAN (T3 NATURAL)

The engine should use T1_UK and T2_UK:

Plan
PLAN (V1 T1 INDEX (T1_UK1))
PLAN (V1 T2 INDEX (T2_UK1))
PLAN (T3 NATURAL)

Without coalesce in then where clause it works fine:

select t3.id,
       (select first 1 v1.id
          from v1
          where v1.vc1 = 'A' and v1.i2 = 1000 and v1.i1 = t3.i1_1)
  from t3
Plan
PLAN (V1 T1 INDEX (T1_UK1))
PLAN (V1 T2 INDEX (T2_UK1))
PLAN (T3 NATURAL)

and

select t3.id,
       (select first 1 v1.id
          from v1
          where v1.vc1 = 'A' and v1.i2 = 1000 and v1.i1 = t3.i1_2)
  from t3
Plan
PLAN (V1 T1 INDEX (T1_UK1))
PLAN (V1 T2 INDEX (T2_UK1))
PLAN (T3 NATURAL)

====== Test Details ======

Deferred until core-2975 will be fixed (currently 2.5.x produces still bad plan: PLAN MERGE (SORT (JOIN (T1 INDEX (T1_COL), T2 INDEX (T2_ID))), SORT (T3 NATURAL)); 3.0 & 4.0: PLAN HASH (JOIN (T1 INDEX (T1_COL), T2 INDEX (T2_ID)), T3 NATURAL) )

@firebird-automations
Copy link
Collaborator Author

Commented by: Omacht András (aomacht)

database for the test case

@firebird-automations
Copy link
Collaborator Author

Modified by: Omacht András (aomacht)

Attachment: FB_TEST.ZIP [ 12650 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Looks like a duplicate for CORE2975.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue duplicates CORE2975 [ CORE2975 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Omacht András (aomacht)

Dmitry, yes, it looks like it's the same problem.
Is it possible to fix it soon? (FB 2.5, 3.0)

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

I'll try, but no promises.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Duplicate [ 3 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

QA Status: No test

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Resolved [ 5 ] => Resolved [ 5 ]

QA Status: No test => Deferred

Test Details: Deferred until core-2975 will be fixed (currently 2.5.x produces still bad plan: PLAN MERGE (SORT (JOIN (T1 INDEX (T1_COL), T2 INDEX (T2_ID))), SORT (T3 NATURAL)); 3.0 & 4.0: PLAN HASH (JOIN (T1 INDEX (T1_COL), T2 INDEX (T2_ID)), T3 NATURAL) )

@dyemanov
Copy link
Member

The research shows that it's not related to CORE-2975 (#3357), instead it's related to CORE-4927 (#5218) and was fixed in v2.5.5. Firebird v3.0 was not affected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants