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" <psergey@askmonty.org> To: <maria-developers@lists.launchpad.net> Cc: <timour@askmonty.org>; <igor@askmonty.org>; "Philip Stoev" <pstoev@askmonty.org>; <sanja@askmonty.org> Sent: Tuesday, October 18, 2011 8:01 PM Subject: optimizer_switch flags for next 5.3 release
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