Created
April 28, 2021 12:55
-
-
Save spetrunia/a15e9b68d5b5bc6c0d2e33fa5debcb3e to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
== Check cheaper parts of WHERE first == | |
Consider two queries: | |
Q1: select * from t1 where exists(select 1 from t2 where t2.col=t1.col2) and t1.col1<3 | |
Q2: select * from t1 where t1.col1<3 and exists(select 1 from t2 where t2.col=t1.col2) | |
Suppose both are executed by scanning table t1 and reading each row. Suppose | |
we have any idea about the selectivities of the "t1.col1<3" or "exists(select | |
...)" clauses. | |
It is obvious that it is better to first check the condition that's cheaper to | |
evaluate, that is "t1.col1<3", and then check "exists(select ...)". | |
MariaDB codebase doesn't have a function to get the cost of computing an | |
expression. We suggest to adopt this simple metric: | |
- a subquery costs SUBQUERY_ITEM_COST=10 | |
- a stored function call costs SF_CALL_COST=50 | |
- a function (or a comparison) costs | |
Sum(costs to compute arguments) + (SCALAR_OP_COST=0.01) | |
-- that is, just a column reference costs 0.01. | |
having adopted this metric, walk each AND-OR expression and re-order the | |
conjuncts (or disjuncts) so that cheaper ones come first. | |
The re-ordering should be done at query plan refinement stage, after | |
make_join_select(). (Look at make_join_select() to see where it attaches | |
the conditions) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment