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" To: Cc: ; ; "Philip Stoev" ; 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