diff options
author | unknown <timour@askmonty.org> | 2013-01-17 16:08:05 +0200 |
---|---|---|
committer | unknown <timour@askmonty.org> | 2013-01-17 16:08:05 +0200 |
commit | d51f96b16754cad5d2c9a91bb5b5e0673e59ded0 (patch) | |
tree | 772b0f535ebb2b4a47b3d8333ef5685a8a103cf0 /sql/rpl_rli.h | |
parent | 8a296e6ca2e55f9f1f3ce25d311291a20ee1c9e7 (diff) | |
download | mariadb-git-d51f96b16754cad5d2c9a91bb5b5e0673e59ded0.tar.gz |
MDEV-3900 Optimizer difference between MySQL and MariaDB with stored functions in WHERE clause of UPDATE or DELETE statements
Analysis
The reason for the less efficient plan was result of a prior design decision -
to limit the eveluation of constant expressions during optimization to only
non-expensive ones. With this approach all stored procedures were considered
expensive, and were not evaluated during optimization. As a result, SPs didn't
participate in range optimization, which resulted in a plan with table scan
rather than index range scan.
Solution
Instead of considering all SPs expensive, consider expensive only those SPs
that are non-deterministic. If an SP is deterministic, the optimizer will
checj if it is constant, and may eventually evaluate it during optimization.
Diffstat (limited to 'sql/rpl_rli.h')
0 files changed, 0 insertions, 0 deletions