May 2016 - developers - lists.mariadb.org

[Maria-developers] Cassandra v2 Project Blog and git setup.
by Charles Muurmu 12 May '16

12 May '16

Hi everyone, I am not used to blogging but I have created a wordpress blog on which I will be making posts about my progress on this project with Spetrunia. Please feel free to criticize and suggest corrections. So far I have forked the code to my Github and my work will be based on 10.1. <https://github.com/charlesmuurmu/server> I have build the code on OS X El Capitan. I have also created a branch in which I will be working. I am currently going through some documentation and tutorials on the Datastax C++ driver. Regards, Biggy

2 3

Re: [Maria-developers] GSoC Student Introduction
by Sergey Petrunia 11 May '16

11 May '16

On Wed, May 11, 2016 at 08:26:49PM +0300, Sergey Petrunia wrote: > On Wed, Apr 27, 2016 at 07:44:11AM +0100, Charles Muurmu wrote: > > I am Charles Muurmu also known as laserlight on IRC and I was selected for > > GSoC 2016 to work on migrating MariaDB Cassandra storage engine from the > > Thrift API to Datastax driver. I will be mentored by Spetrunia. My goals > > for this community bonding period will be get myself ready by accomplishing > > the following tasks: > > > > Fork and clone the server code. > > > > Try to build the code. > > > > Setup a blog on which I will post weekly reports on progress. > > > > Study the Datastax C++ driver API and documentation. > > When CassandraSE V1 was in development, I was unable to use CQL, because Thrift API was such that the entire CQL resultset had to be materialized before it could be sent to the client. That is, running "select * from column_family" would cause the cassandra node and/or MySQL to die from attempting to use too much memory. I'm interested to learn how this is resolved in the Datastax driver. > > Study the ha_cassandra.xx code and storage engines architecture. > > > Good plan. > > Hopefully the last two items will give a better idea about how to structure the > coding (what to do as the first, second, etc milestone). Another question to think about is data models. Use of Thrift API calls in CassandraSE V1 meant that - secondary indexes could not be used - there were some other limitation on what datatypes could be used (I don't remember what they were exactly). Now, if we are using CQL, it should be possible to use those. Maybe there's also something else that I'm not aware of. BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] Please review MDEV-10051 Fix subselect to return a syntax error instead of "Incorrect usage of UNION and LIMIT"
by Alexander Barkov 11 May '16

11 May '16

Hello Sergei, Please review the next step for MDEV-8909 union parser cleanup Now it's MDEV-10051, and it fixes subselects. Note, I decided to fix derived tables in a separate patch later. So there will be one more patch blocking MDEV-8909. Thanks!

2 1

[Maria-developers] MDEV-10036 sql_yacc.yy: Split select_part2 to disallow syntactically bad constructs with INTO, PROCEDURE, UNION
by Alexander Barkov 10 May '16

10 May '16

Hi Sergei, Please review a patch for MDEV-10036. This is the next step for: MDEV-8909 union parser cleanup Thanks!

2 2

[Maria-developers] Please review MDEV-10030 sql_yacc.yy: Split table_expression and remove PROCEDURE from create_select, select_paren_derived, select_derived2, query_specification
by Alexander Barkov 09 May '16

09 May '16

Hi Sergei, Please review a patch for MDEV-10030, which is a part of MDEV-8909 union parser cleanup. Thanks!

2 4

[Maria-developers] GSoC 2016: Starting blog
by Галина Шалыгина 07 May '16

07 May '16

Hi everyone, I have created blog, where I'm going to write everything about my progress on project "Pushing conditions into non-mergeable views and derived tables in MariaDB". I've already written a post on what I've done, so if you are interested, you can check it out HERE <http://gsocmariadbshagalla.blogspot.ru/>. Best wishes, Galina Shalygina.

1 0

[Maria-developers] Joinable threads
by Sergey Vojtovich 06 May '16

06 May '16

Hi Monty, I vaguely recall you told me once that you like detached threads more than joinable, specifically for service threads. Could you remind me what were the reasons behind it? I need this to fix https://jira.mariadb.org/browse/MDEV-9994 properly. Thanks, Sergey

2 4

Re: [Maria-developers] [MariaDB/server] MDEV-9857: line cache size (to 10.1) (#169)
by Kristian Nielsen 06 May '16

06 May '16

Sergey Vojtovich <notifications(a)github.com> writes: > Since Alexey's patch wasn't yet accepted by MySQL we need his > confirmation that we can take it under BSD-new or MCA > terms. @akopytov, could you confirm? That _really_ is completely ridiculous! So here we have a patch. You will gladly accept it from MySQL/Oracle under GPL v2, without any special conditions. But the very same patch, submitted directly by the original author, you will not take??!? Now, obviously this is not something Sergey Vojtovich invented on his own, I doubt he even agrees personally. So Otto, you specifically asked me to be more vocal about MariaDB Foundation issue. Can we please have your personal opinions on this idea of BSD/contributer agreement for selected potential contributers? I have from the very start of MariaDB been strongly opposed to any form of contributer agreements or reciprocal licensing. Fortunately, we never really had it in practice, since all major contributions (MySQL@Oracle, XtraDB, oqgraph, sphinx, tokudb, galera, ...) were GPL only. But recently we have this message to potential contributers that the MariaDB Foundation "needs" to have BSD or MCA. This is extremely disrespectful for at least two reasons: - There clearly is no such "need", since the Foundation receives GPL rights only to a large part of new contributions to MariaDB - for example from Galera, MySQL@Oracle, Percona. - Selected contributers are except from this requirement. For example, according to my information, large parts of the MariaDB code to which the company SkySQL/MariaDB Corporation has full rights, they are _not_ required to provide BSD/MCA for to the MariaDB Foundation. Otto, I strongly encourage you to look to other successful Free Software projects such as the Linux Kernel, where an important part of the success is the deliberate choice of GPL-only _without_ any reciprocal licensing. I urge you to re-consider, and take a personal stance against this BSD/MCA nonsense, and work strongly for an official GPL-only contributer policy. Meanwhile, I encourage all contributers to _not_ accept this BSD/MCA requirement. If you disagree, be aware that there is no such strong requirement, and the major part of contributions to MariaDB are done without this requirement. If your contribution is accepted, but under condition of BSD/MCA, and you disagree, ask on the mailing list for someone else with commit rights to push your patch. I am sure there are several that will be willing to do so. - Kristian.

3 5

[Maria-developers] MDEV-9712 Performance degradation of nested NULLIF
by Alexander Barkov 05 May '16

05 May '16

Hello Sergei, Please have a look into a draft fix for MDEV-9712. The problem happens because in 10.1 execution time for various recursive stages (like walk, update_used_table and propagate_equal_fields) in NULLIF is O(recursion_level^2), because complexity is doubled on every recursion level when we copy args[0] to args[2]. This fix simplifies some stages to make them faster. It reduced execution time from 144 seconds to 12 seconds. The idea is just not to iterate through args[2] when it's just a copy of args[0] in these stages: - Item_func_nullif::walk - Item_func_nullif::update_used_tables I'm not fully sure that skipping args[2] is always correct though. For some transformers it may not be correct. <offtopic> Btw, walk() can be called from the partitioning code when arg_count is still 2 rather than 3. Looks suspicious. Perhaps there is a hidden bug behind that. </offtopic> The remaining heavy piece of the code is: Item* propagate_equal_fields(THD *thd, const Context &ctx, COND_EQUAL *cond) { Context cmpctx(ANY_SUBST, cmp.compare_type(), cmp.compare_collation()); args[0]->propagate_equal_fields_and_change_item_tree(thd, cmpctx, cond, &args[0]); args[1]->propagate_equal_fields_and_change_item_tree(thd, cmpctx, cond, &args[1]); args[2]->propagate_equal_fields_and_change_item_tree(thd, Context_identity(), cond, &args[2]); return this; } We cannot use the same approach here, because args[0] and args[2] are propagated with a different context (ANY_SUBST vs IDENTITY_SUBST). Not sure what to do with this. Perhaps, data types could have an extra attribute to tell that ANY_SUBST and IDENITTY_SUBST are equal. So, for example, for non-ZEROFILL integers, ANY_SUBST and IDENTITY_SUBST do the same thing and thus propagation could be done one time only. But this would be a partial solution, for a limited number of data types. Another option is to leave propagation as is. Another option is do nothing at all. If we rewrite the reported query as CASE, it will look heavy indeed. So it's Ok to expect heavy execution complexity. Thanks.

2 3

[Maria-developers] UNION + INTO OUTFILE is confusing
by Alexander Barkov 04 May '16

04 May '16

Hi Sergei, If I run this query: SELECT 1 UNION SELECT 2 INTO OUTFILE 'test.txt'; It creates a file 'test.txt' with this content: 1 2 Looks fine so far. Now if I do "rm test.txt" and execute another query (with parentheses): (SELECT 1) UNION (SELECT 2 INTO OUTFILE 'test.txt'); it still puts the same two records from both UNION parts! This looks confusing, as parentheses a kind of assume that only the right UNION part is to be exported. Exporting only one UNION part is not supported, IIRC. So the above query should probably return a syntax error. But now there is a new trouble. There is no syntax like this: (SELECT ...) UNION (SELECT ...) INTO OUTFILE 'test.txt'; So instead of: (SELECT ...) UNION (SELECT ... INTO OUTFILE 'test.txt'); one will have to write this: SELECT * INTO OUTFILE 'test.txt' FROM ((SELECT ...) UNION (SELECT ...)) AS t1; The latter looks longer, but at least it's not confusing as the former.

2 2