Issue Details (XML | Word | Printable)

Key: CORE-3553
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dmitry Yemanov
Reporter: Volker Rehn
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
Firebird Core

Nested loop plan is chosen instead of the sort merge for joining independent streams using keys of different types

Created: 12/Jul/11 05:44 PM   Updated: 16/May/12 01:03 PM
Component/s: Engine
Affects Version/s: 2.1.4
Fix Version/s: 2.5.1, 2.1.5, 3.0 Alpha 1

Time Tracking:
Not Specified

Issue Links:
Relate

Planning Status: Unspecified


 Description  « Hide
Formally, this is a performance regression introduced while fixing CORE-1274 and CORE-1752. Now, instead of sorting/merging the streams which delivered wrong results, a safer nested loop join method is chosen. Unfortunately, it's also much slower if the streams are independent. As it was an intended change, it doesn't count as a bug per se, more as a "lesser evil". But better solutions are possible.

Artificial test case:

select count(*)
from rdb$database d1 join rdb$database d2
  on cast(d1.rdb$relation_id as char(10)) = cast(d2.rdb$relation_id as char(20))

-- Reported (bad) plan:
-- PLAN JOIN (D1 NATURAL, D2 NATURAL)

-- Expected (good) plan:
-- PLAN MERGE (SORT (D2 NATURAL), SORT (D1 NATURAL))

All branches are affected, but v2.1.4 is the only released version which has the issue. The workaround is to explicitly cast the join keys to the same data type.

 All   Comments   Work Log   Change History   Version Control   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Dmitry Yemanov added a comment - 12/Jul/11 05:45 PM
@ Volker: the workaround in your case is:

select o.objekt, o.beschreibung, o.modultext, o.thema, o.feldtyp
from get_w_objektlookup('FAC') o
join get_mcb_modul(5) m on m.modul = cast(o.modul as varchar(30))
order by 4,3,2