[Maria-developers] optimizer_switch flags for next 5.3 release
![](https://secure.gravatar.com/avatar/bccaf81a23eecaecd9feaf01c7c42ff4.jpg?s=120&d=mm&r=g)
Hi, Written down notes from discussion about which flags should be enabled by default in the next 5.3 release: - Derived tables and keys in them should be enabled - BKA should not be enabled (doesn't make sense for 'default' query loads) - semi-joins should be enabled - Materialization (base) should be enabled - extra strategies for NULL-aware materialization - ??? - ICP should be enabled - Hash join could be enabled but in the next minor release. - Cost-based MRR should not be enabled as cost model is not tuned. when some feature is considered stable enough, its owner should apply for testing with {$current_optimizer_switch_default+new_feature}, and once that is passed, change the default in the main branch. BR Sergey -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
![](https://secure.gravatar.com/avatar/098e1158b4929d68397eba5a1a6f2138.jpg?s=120&d=mm&r=g)
Hello,
To make it definitive, I am going to perform all future test runs with the
following options
--join_cache_level=8
ON:
derived_merge=ON,derived_with_keys=ON,index_condition_pushdown=ON,mrr=ON,mrr_sort_keys=ON,semijoin=ON,subquery_cache=ON,join_cache_hashed=ON
OFF:
materialization=OFF,loosescan=OFF,firstmatch=OFF,partial_match*=OFF,join_cache_bka=OFF,mrr_cost_based=OFF
until some other options become ready and available for testing.
Materialization requires an audit of pending bugs plus as far as I
understood code hacks to disable it for NOT IN, so I am not going to enable
it until told otherwise.
Please let me know if I have misunderstood.
Thank you.
Philip Stoev
----- Original Message -----
From: "Sergei Petrunia"
Hi,
Written down notes from discussion about which flags should be enabled by default in the next 5.3 release:
- Derived tables and keys in them should be enabled - BKA should not be enabled (doesn't make sense for 'default' query loads) - semi-joins should be enabled - Materialization (base) should be enabled - extra strategies for NULL-aware materialization - ??? - ICP should be enabled - Hash join could be enabled but in the next minor release.
- Cost-based MRR should not be enabled as cost model is not tuned.
when some feature is considered stable enough, its owner should apply for testing with {$current_optimizer_switch_default+new_feature}, and once that is passed, change the default in the main branch.
BR Sergey -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
participants (2)
-
Philip Stoev
-
Sergei Petrunia