[Maria-developers] Preparations for 5.3.2 release
Hi! As discussed on the yesterday's call, we're starting to prepare for the next 5.3 release, 5.3.2 beta. The intent is to build it on this or on the next weekend. Before the release, we need to do 1. Bugs 2. optimizer_switch changes. 3. Merge from mariadb-5.1 We don't need to address: 1. Pushing Kristian's replication features. If I heard correctly, the decision was that they won't be pushed into 5.3 (please correct me if I am wrong) == Bugs == Current situation with 5.3-targeted bugs is as follows: Crashing bugs: - SergeyP: 3 + 2 non-repeatable (#860535 #860553 #861147 #860561 (non-repeatable) #860580 (non-repeatable)) - Timour: 2 (#824425 #858148) - Nobody: 1 (#859375) Wrong query result bugs: - Timour: 8 (#858038 #817966 #833777 #825051 #826150 #747278 #833702 #856152) - Igor : 2 (#823301 #791761) - Sanja: 1 (#825075) I have a slight excuse that all my crasing bugs were filed just yesterday. I'll try to fix them before the release. Another problem area is Timour's crashes + wrong query result bugs. Also, we need to assign #859375. == optimizer_switch changes == Some of the new optimizations are already sufficiently stable so that they can be made enabled by default. >From the code quality point of view, Philip's opinion is: - subquery_cache can be turned ON. - join_cache_level can be set to value higher than 1, and also various variants of BKA/Hash join may be enabled. - MRR can be enabled - index_condition_pushdown can be enabled - Materialization still has bugs, cannot be enabled. - semi-joins+materialization cannot be enabled together, there are bugs. - semi-joins without materialization cause non-repeatable crashes, so cannot be enabled yet. - FROM subqueries/derived tables optimization didn't recieve sufficient testing yet, so cannot be enabled. Note that the above is based only on the number of known crashes/wrong query result problems, performance issues are not counted. My opinion is that - subquery_cache can be enabled. - index_condition_pushdown can be enabled. - I'm hesitant to enable MRR because it may cause slowdowns for small-dataset sysbench-like tests. - perhaps, some part of hash join could be enabled (as far as I understand, its overhead is rather small, so it doesn't cause regressions?) Anybody (and especially feature "owners") have any thoughts? == Merge from MariaDB 5.1 == Monty mentioned we'll need to do it, but nobody took this task? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog
On 09/28/2011 03:36 AM, Sergey Petrunya wrote:
Hi!
As discussed on the yesterday's call, we're starting to prepare for the next 5.3 release, 5.3.2 beta. The intent is to build it on this or on the next weekend.
Before the release, we need to do 1. Bugs 2. optimizer_switch changes. 3. Merge from mariadb-5.1
We don't need to address: 1. Pushing Kristian's replication features. If I heard correctly, the decision was that they won't be pushed into 5.3 (please correct me if I am wrong)
== Bugs ==
Current situation with 5.3-targeted bugs is as follows:
Crashing bugs: - SergeyP: 3 + 2 non-repeatable (#860535 #860553 #861147 #860561 (non-repeatable) #860580 (non-repeatable)) - Timour: 2 (#824425 #858148) - Nobody: 1 (#859375)
Wrong query result bugs: - Timour: 8 (#858038 #817966 #833777 #825051 #826150 #747278 #833702 #856152) - Igor : 2 (#823301 #791761) #791761 was actually fixed (rev.3127)
- Sanja: 1 (#825075)
I have a slight excuse that all my crasing bugs were filed just yesterday. I'll try to fix them before the release.
Another problem area is Timour's crashes + wrong query result bugs.
Also, we need to assign #859375.
== optimizer_switch changes ==
Some of the new optimizations are already sufficiently stable so that they can be made enabled by default.
From the code quality point of view, Philip's opinion is: - subquery_cache can be turned ON. - join_cache_level can be set to value higher than 1, and also We can't do it unless we set a minimum number of rows in join cache that allows using blocked-based join algorithms, or better we calculate the cost of possible usage of join cache and make a fair choice.
various variants of BKA/Hash join may be enabled. - MRR can be enabled - index_condition_pushdown can be enabled
- Materialization still has bugs, cannot be enabled. - semi-joins+materialization cannot be enabled together, there are bugs. - semi-joins without materialization cause non-repeatable crashes, so cannot be enabled yet. - FROM subqueries/derived tables optimization didn't recieve sufficient testing yet, so cannot be enabled.
Note that the above is based only on the number of known crashes/wrong query result problems, performance issues are not counted.
My opinion is that - subquery_cache can be enabled. - index_conditi,on_pushdown can be enabled. My big patch that incorporates InnoDB changes from mysql-5.6 for ICP is still not merged with latest version of 5.3.
Regards. Igor.
- I'm hesitant to enable MRR because it may cause slowdowns for small-dataset sysbench-like tests. - perhaps, some part of hash join could be enabled (as far as I understand, its overhead is rather small, so it doesn't cause regressions?)
Anybody (and especially feature "owners") have any thoughts?
== Merge from MariaDB 5.1 == Monty mentioned we'll need to do it, but nobody took this task?
BR Sergey
- join_cache_level can be set to value higher than 1, and also We can't do it unless we set a minimum number of rows in join cache that allows using blocked-based join algorithms, or better we calculate the cost of possible usage of join cache and make a fair choice.
- index_conditi,on_pushdown can be enabled. My big patch that incorporates InnoDB changes from mysql-5.6 for ICP is still not merged with latest version of 5.3.
Both of those would be fairly major changes that will require additional rounds of testing once they are pushed. The sooner this happens, the better, so please let me know once they are ready. Philip Stoev
participants (3)
-
Igor Babaev
-
Philip Stoev
-
Sergey Petrunya