SJ-Materialization picks scan-strategy which is 2x slower than SJ-Materialization lookup
Bug #806894 reported by
Sergey Petrunia
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MariaDB |
Confirmed
|
Low
|
Sergey Petrunia |
Bug Description
See testcase and details in: https:/
I'm not sure if this is actually a bug (i.e. here we have a situation where the optimizer had sufficient info to make the right decision but didn't make it). This needs to be investigated.
Changed in maria: | |
assignee: | nobody → Sergey Petrunia (sergefp) |
importance: | Undecided → Low |
milestone: | none → 5.3 |
Changed in maria: | |
milestone: | 5.3 → 5.5 |
importance: | Medium → Low |
tags: | added: optimizer |
To post a comment you must log in.
I too am seeing a lot of issues where semijoin is detrimental to use. For my application, subqueries are absolutely essential so I have been running maria 5.3 in production since at least september.
I occasionally run into areas where maria attempts to semijoin and it will cause the query to be 1 or more orders of magnitude slower. Unfortunately, about 1/10 as often I find that semijoin makes some painful queries wickedly fast, so I am forced to leave it on in some cases.
You have this marked as low priority but I would _really_ like to see this fixed for maria 5.3. I do consider this a major bug but semijoin is too optimistic about it's chances to handle some things and can wreak havoc on queries even mysql 5.5 can do faster.