October 2011 - developers - lists.mariadb.org

[Maria-developers] Preparations for 5.3.2 release
by Sergey Petrunya 10 Oct '11

10 Oct '11

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

3 2

[Maria-developers] optimizer_switch default settings change for 5.3.2: status?
by Sergey Petrunya 09 Oct '11

09 Oct '11

Hi Sanja, I was wondering if you have any progress with optimizer_switch default settings change that we decided to do for the 5.3.2 release? Any ETA on when that will be pushed? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] 5.5 merge status
by Kristian Nielsen 07 Oct '11

07 Oct '11

Hi Serg, Here is the status of my efforts to merge the rpl,binlog, and innodb suites. These are the tests that still fail after my last pust to 5.5-serg: binlog.binlog_innodb_row This fails because of a problem in my merge of group commit, I will fix. binlog.binlog_killed I do not know yet, I can take a look next week. binlog.binlog_index This fails because of missing --test-expect-abort option which you said you would re-add back. rpl.rpl_create_if_not_exists Something with CREATE IF NOT EXISTS, I believe you said you would look at this (not related to replication). rpl.rpl_variables_stm This looks like microsecond related, maybe you can check. innodb.innodb innodb.innodb_no_mrricp innodb.innodb_mysql I think we should ask someone from optimiser to take a look at these. - Kristian.

3 3

[Maria-developers] Out of semi-join bugs, time for another testing?
by Sergey Petrunya 06 Oct '11

06 Oct '11

Hi Philip, I've fixed/pushed all semi-join bugs. If I recall correctly, you intended to do more semi-join testing, now everything is ready for it. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

Re: [Maria-developers] MySQL Bug 59449 - Accepted by MariaDB?
by Jeremy Thomerson 05 Oct '11

05 Oct '11

Cool, thank you! As I'm not very familiar with the working process between MariaDB and MySQL upstream, do you think this patch will go back upstream? My intention in my original work on it was to get a fix into all distros that track MySQL. Thanks again! Jeremy Thomerson On Wed, Oct 5, 2011 at 8:56 AM, Timour Katchaounov <timour(a)montyprogram.com>wrote: > Hello Jeremy, > > This is to inform you that I started working on > MySQL Bug 59449. In order to track the bug progress > I created a bug in Launchpad: > https://bugs.launchpad.net/**maria/+bug/861763<https://bugs.launchpad.net/maria/+bug/861763> > > If you are interested in following the progress of > this work, please subscribe to the Launchpad bug above. > > I will work on implementing the generic solution > suggested by Monty. > > Timour > > > >> Hi! >> >> "Jeremy" == Jeremy Thomerson<jeremy(a)**thomersonfamily.com<jeremy(a)thomersonfamily.com>> >>>>>>> writes: >>>>>>> >>>>>> >> Jeremy> Monty, et al... >> Jeremy> On Mon, Jun 13, 2011 at 9:36 AM, Michael Widenius< >> monty(a)askmonty.org>**wrote: >> >> >>>> Hi! >>>> >>>> "Sergei" == Sergei Golubchik<serg(a)askmonty.org> writes: >>>>>>>>> >>>>>>>> >>>> Sergei> Hi, Jeremy! >> Sergei> On Jun 10, Jeremy Thomerson wrote: >> >>> I just submitted a patch to a MySQL bug that I am also experiencing. I >>>>>> would like to see it accepted into the wider community (MySQL, >>>>>> MariaDB, >>>>>> Percona, etc). Please let me know what I need to do so that this >>>>>> patch >>>>>> could also be accepted into your project. >>>>>> >>>>>> The bug is here: http://bugs.mysql.com/bug.php?**id=59449<http://bugs.mysql.com/bug.php?id=59449> >>>>>> The "[11 Jun 3:16] Jeremy Thomerson" comment will be the most useful. >>>>>> >>>>> >>>> >> >> Sergei> But if Oracle will refuse to fix this bug, we will look at your >> >>> patch, >>>> >>> Sergei> certainly. >> >>> >>>> To ensure we don't forget about this, if you are not sure that Oracle >>>> has fixed the bug within one month, ping us and we will look at >>>> adding this into MariaDB at once. >>>> >>>> >> Jeremy> Thanks a bunch! I was away a lot in July and August and didn't >> get to >> Jeremy> follow up on this. Looking at the original bug report, I have >> seen >> Jeremy> absolutely no activity. I'm not even sure why they have not >> touched / >> Jeremy> accepted it. If anyone here knows a way to get it into one (or >> both) >> Jeremy> projects, I'd appreciate any help you can offer. >> >> The patch you suggested was: >> >> === modified file 'sql/sql_base.cc' >> --- sql/sql_base.cc 2011-04-12 10:59:59 +0000 >> +++ sql/sql_base.cc 2011-06-10 20:11:52 +0000 >> @@ -6975,6 +6975,28 @@ >> *counter= i; >> *resolution= RESOLVED_IGNORING_ALIAS; >> break; >> + } >> + else if (find->type() == Item::FUNC_ITEM&& ((Item_func*) >> find)->functype() == Item_func::COLLATE_FUNC&& ((Item_func*) >> find)->arg_count == 2) >> >> + { >> + /* >> + If someone uses "ORDER BY column_name COLLATE utf8_spanish_ci", >> it is a function >> + that we are trying to find, and not a real column. Bug #59449 >> exposes that this >> + failed when column_name is actually referring to the name of an >> alias, whether >> + that alias is for a real column or for a function result (such >> as coalesce). This >> + block of code finds the real item, which is the "column" >> referred to by the >> + collation function for this scenario. >> + */ >> + Item *collated_column = ((Item_func*) find)->arguments()[0]; >> + int is_alias = item->type() == Item::FUNC_ITEM || >> + ((item->type() == Item::FIELD_ITEM || item->type() >> == Item::REF_ITEM)&& >> + my_strcasecmp(system_charset_**info, >> ((Item_ident*) item)->field_name, item->name)); >> + if (is_alias&& collated_column->name&& item->name&& >> !my_strcasecmp(system_charset_**info, item->name, >> collated_column->name)) >> >> + { >> + found =&collated_column; >> + *counter = i; >> + *resolution = RESOLVED_BEHIND_ALIAS; >> + break; >> + } >> } >> } >> else if (table_name&& item->type() == Item::REF_ITEM&& >> >> What I don't like with the patch is that we make COLLATE a special >> case. I think that all usage of alias names in ORDER BY should be >> treated the same. >> >> In other words: >> >> ORDER BY LanguageName >> ORDER BY LanguageName COLLATE utf8_spanish_ci >> ORDER BY concat(LanguageName,"aa") >> >> should all use either the column or the alias in the same manner. >> >> As we normally prefer alias for a column name in the ORDER BY, >> I think we should fix this so that we always prefer the alias name in >> all ORDER BY context. >> >> The other option would be to give an error in this case as it's not >> clear what the user wants. This is hower likely to break many old >> applictions. >> >> After talking with Sergei, he concluded: >> >> "yes, I believe now that according to the SQL:2003 (ISO/IEC >> 9075-2:2003, part 2 (foundations), 14.1<declare cursor>, Syntax >> Rules, item 18) aliases from the select list take precedence over >> column names from the table" >> >> The standard is very vague in the area, but it seams to support the >> idea that alias'es should resolve first). >> >> This means that we should fix things to always first prefer alias. >> The fix in this case needs to be done in item::fix_fields() and not in >> sql_base.cc >> >> I will ask Timour to see if he can provide a fix for this. >> (As he knows the fix_fields code quite well and he needs something to >> bite into now when he is back from his vacation). >> >> Timour, can you handle this? >> >> Regards, >> Monty >> >

1 0

[Maria-developers] WL#240 New (by Mdcallag): client-side compressed types
by worklog-noreply＠askmonty.org 03 Oct '11

03 Oct '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: client-side compressed types CREATION DATE..: Fri, 30 Sep 2011, 20:31 SUPERVISOR.....: IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Client-BackLog TASK ID........: 240 (http://askmonty.org/worklog/?tid=240) VERSION........: WorkLog-4.0 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Is it possible to add a variant of the blob types that is compressed on the client side? By this I mean that the client library handles compression and decompression so that the client code does not have to deal with it. The benefit from this is reduced load. There will be less network traffic between client/server and master/slave. This uses less space in the binlog, relay log, innodb transaction log and database files. The alternative is to use compression between client/server and master/slave but that doesn't help with the size of the binlog file nor with the innodb datafiles or log file. We have too many cases where huge text/blob values store uncompressed JSON and the bloat from that hurts performance. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

4 4