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

Results of a join with different collations depend on the execution plan [CORE1752] #2177

Closed
firebird-automations opened this issue Feb 20, 2008 · 15 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: Volker Rehn (vr2_s18)

Is related to CORE1274
Is related to QA269
Relate to CORE3553

Attachments:
test.fbk

with test case, db uses charset ISO8859-1

select a.zeitstempel, b.artikelnr
from t1 a
join t2 b on b.artikelnr = a.artikelnr --collate de_de

gives 5 records

uncomment collate de_de and it gives 9 records, the correct result. Using collate affects the execution plan and enables optimizer to find all matching records.

Commits: 9dfe2fe 9fe05cc 2f28556

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

Plans in 3.0:
Query-1: PLAN SORT (JOIN (A NATURAL, B NATURAL))
Query-2: PLAN SORT (HASH (B NATURAL, A NATURAL))

Plans in 2.5:
Query-1: PLAN SORT (JOIN (A NATURAL, B NATURAL))
Query-2: PLAN SORT (MERGE (SORT (B NATURAL), SORT (A NATURAL)))

It was decided to SKIP comparison of actual stdout with these plans because in 3.0 it can be changed.

@firebird-automations
Copy link
Collaborator Author

Commented by: Volker Rehn (vr2_s18)

connect using charset ISO8859-1

@firebird-automations
Copy link
Collaborator Author

Modified by: Volker Rehn (vr2_s18)

Attachment: test.fbk [ 10774 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: Sean Leyne (seanleyne)

Volker,

Why would you add a collate to a JOIN?

@firebird-automations
Copy link
Collaborator Author

Commented by: Kuznetsov Eugene (eugene)

It seems, it's special case of CORE1274

Best regards, Eugene

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue is related to CORE1274 [ CORE1274 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 3.0 Alpha 1 [ 10331 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

summary: results of join with different collations depend on execution plan => Results of a join with different collations depend on the execution plan

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

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

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Collaborator Author

Commented by: @dyemanov

Backported into v2.5.1 and v2.1.4.

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Fix Version: 2.1.4 [ 10361 ]

Fix Version: 2.5.1 [ 10333 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

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

@firebird-automations
Copy link
Collaborator Author

Modified by: @pcisar

Link: This issue is related to QA269 [ QA269 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

Link: This issue relate to CORE3553 [ CORE3553 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @pavel-zotov

status: Closed [ 6 ] => Closed [ 6 ]

QA Status: Done successfully

Test Details: Plans in 3.0:
Query-1: PLAN SORT (JOIN (A NATURAL, B NATURAL))
Query-2: PLAN SORT (HASH (B NATURAL, A NATURAL))

Plans in 2.5:
Query-1: PLAN SORT (JOIN (A NATURAL, B NATURAL))
Query-2: PLAN SORT (MERGE (SORT (B NATURAL), SORT (A NATURAL)))

It was decided to SKIP comparison of actual stdout with these plans because in 3.0 it can be changed.

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