Skip to content

Instantly share code, notes, and snippets.

@spetrunia
Created April 28, 2021 12:55
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save spetrunia/a15e9b68d5b5bc6c0d2e33fa5debcb3e to your computer and use it in GitHub Desktop.
Save spetrunia/a15e9b68d5b5bc6c0d2e33fa5debcb3e to your computer and use it in GitHub Desktop.
== 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