- developers - lists.mariadb.org

[Maria-developers] EXPLAIN in the slow query log
by Sergei Petrunia 12 Nov '13

12 Nov '13

Hello, After recent changes in the [SHOW] EXPLAIN architecture in MariaDB, it became really easy to add an option to print EXPLAIN(*) output into the slow query log, so I went ahead and implemented it. @@log_slow_verbosity has got a 'explain' flag, and if it is on, the slow query log entries look like this: # Time: 131017 21:26:02 # User@Host: root[root] @ localhost [] # Thread_id: 2 Schema: dbt3sf1 QC_hit: No # Query_time: 5.535819 Lock_time: 0.000350 Rows_sent: 1 Rows_examined: 65633 ## <explain> ## id select_type table type possible_keys key key_len ref rows Extra ## 1 SIMPLE nation ref PRIMARY,n_name n_name 26 const 1 Using where; Using index ## 1 SIMPLE customer ref PRIMARY,i_c_nationkey i_c_nationkey 5 dbt3sf1.nation.n_nationkey 25124 Using index ## 1 SIMPLE orders ref i_o_custkey i_o_custkey 5 dbt3sf1.customer.c_custkey 7 Using index ## </explain> SET timestamp=1382030762; select count(*) from customer, orders, nation where c_custkey=o_custkey and c_nationkey=n_nationkey and n_name='GERMANY'; It seems, pt-slow-query-log has no problem parsing this. Open questions: - Is this syntax OK? - Currently, some statements (like SHOW KEYS) print a dumb explain that shows that full table scan is used. There is a suggestion to not print EXPLAIN for any SHOW statements. Is this ok? (*) something like EXPLAIN ANALYZE, with numbers from actual execution, would be better but we are not there yet. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

5 6

[Maria-developers] A newer InnoDB in 10.0 series?
by Colin Charles 12 Nov '13

12 Nov '13

Hi! I see that we are shipping InnoDB from 5.6.5 (at least that's what the plugin version tells me - 1.2.5). Are we going to pop XtraDB or a modern InnoDB into 10.0.6? Thanks -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

3 3

Re: [Maria-developers] [Commits] Rev 3886: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. in file:///home/hf/wmar/10exp/
by Jan Lindström 11 Nov '13

11 Nov '13

Hi, MySQL changes look good, InnoDB changes need some work that I will do, please do not push those. R: Jan > At file:///home/hf/wmar/10exp/ > > ------------------------------------------------------------ > revno: 3886 > revision-id: holyfoot(a)askmonty.org-20131108110551-j0rxpxrnfertay2q > parent: knielsen(a)knielsen-hq.org-20131107065240-gxxg4ilcs8o2v0q2 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: 10exp > timestamp: Fri 2013-11-08 15:05:51 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option, > another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>

1 0

Re: [Maria-developers] patch to upgrade collations
by Michael Widenius 08 Nov '13

08 Nov '13

Hi! >>>>> "Alexander" == Alexander Barkov <bar(a)mariadb.org> writes: Alexander> Hi Monty, Alexander> Please find the full patch attached. Alexander> Greetings. Here is a modified patch that also fixes that REPAIR works. It doesn't include the myisam files that you had in your patch, but it will of course need these. I have verified that all test cases you changed works. Regards, Monty

1 0

[Maria-developers] MDEV-4954
by Sergei Golubchik 08 Nov '13

08 Nov '13

Hi, Oden could you please take a look at MDEV-4954? https://mariadb.atlassian.net/browse/MDEV-4954 "RPM Packaging Removes Config File" The complain is that when one uninstalls MariaDB, /etc/my.cnf gets "removed" (actually, renamed to /etc/my.cnf.rpmsave). And MySQL packages don't do that (because they don't include my.cnf at all). Anything we can do to make the user happier? Regards, Sergei

1 0

[Maria-developers] Debian/Ubuntu packages
by Matt Coleman 07 Nov '13

07 Nov '13

Hello, I’m working on fixing the dependency issues with MariaDB 5.5.33a vs MySQL 5.5.34. When I’m ready to publish my fix, what version number should I give it? The current packages have the version 5.5.33a+maria-1~CODENAME, where CODENAME is the code name for the Debian or Ubuntu release (ie. “sid” or “precise”, etc). Since I am not changing any code, it seems like like 5.5.33a should remain the same. I expected that the fixed package would be 5.5.33a+maria-2~CODENAME, but autobake-deb.sh assembles that version string and the 1 is hardcoded, not set by a variable. The two variables RELEASE_NAME and RELEASE_EXTRA can insert text between “+maria-“ and “1”. What is this project’s versioning convention in regards to changes that only affect the packaging? Matt

2 2

Re: [Maria-developers] [Commits] Rev 3942: MDEV-5205 - MariaDB does not start if more than 128 cpu's are available
by Sergei Golubchik 06 Nov '13

06 Nov '13

Hi, Sergey! On Nov 06, Sergey Vojtovich wrote: > ------------------------------------------------------------ > revno: 3942 > revision-id: svoj(a)mariadb.org-20131106185339-wjz3xuru8ojnz00l > parent: monty(a)askmonty.org-20131105183036-051tak9a2fq9ii05 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5205 > timestamp: Wed 2013-11-06 22:53:39 +0400 > message: > MDEV-5205 - MariaDB does not start if more than 128 cpu's are available > > An addition to fix for MDEV-5205, fixes server crash on shutdown. > > Thread groups are destroyed asynchronously, that is kill server > thread sends shutdown request to all thread groups without waiting > for compeltion. > > It means all_groups array must not be freed until all thread groups > are down. This patch suggests that all_groups is freed when last > thread group is destroyed. Looks reasonable. ok to push Regards, Sergei

1 0

[Maria-developers] MariaDB 10.0.5 Beta Release Prep
by Daniel Bartholomew 05 Nov '13

05 Nov '13

I'm currently in the process of preparing for the MariaDB 10.0.5 Beta release. Draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-1005-release-notes/ - https://mariadb.com/kb/en/mariadb-1005-changelog/ The release notes page is not much more than a template at present and needs to be be filled in before the release. Please add any items that should be there ASAP. Current plans are to activate and announce the release tomorrow (6 Nov). Thanks. -- Daniel Bartholomew MariaDB

1 0

[Maria-developers] Opened_plugin_libraries status variable
by Ian Gilfillan 05 Nov '13

05 Nov '13

Hi I would like to document the Opened_plugin_libraries status variable, introduced in MariaDB 10.0, but can't understand what it's all about. I have looked at: http://lists.askmonty.org/pipermail/commits/2013-April/004595.html but it's not really making sense what it's testing. In my own setup, each time I query the INFORMATION_SCHEMA.ALL_PLUGINS table, Opened_plugin_libraries increments by 19 (no matter what conditions I apply). The only correlation I can find is that there are 19 records with the LOAD_OPTION = 'OFF'. Is this what Opened_plugin_libraries is recording? Why does it increment each time I query the table (19, 38, 57 etc) - how is this useful? Can someone clarify exactly what this variable records, and how it's useful? thanks, ian

2 1

[Maria-developers] On how to fix indentation and history in sql_join_cache.cc
by Sergei Petrunia 05 Nov '13

05 Nov '13

Hi Sanja, My experiment was successfull. It seems, one can fix identation in sql_join_cache.cc so in the following way: # Create a branch in a state "right after the problem" bzr branch -rsanja(a)askmonty.org-20121223213711-ac5vz2fspwapjvtr 10.0 work-maria-10.0-base-cassandra-look1 # The -r3457 branch shows the state "right before the merge that borked it" bzr branch -r3457 work-maria-10.0-base-cassandra-look1 work-maria-10.0-base-cassandra-look1-r3457 cd work-maria-10.0-base-cassandra-look1-r3457 # Do some dummy change to force a merge gvim sql/sql_join_cache.cc bzr gcommit # Prepare the branch where we will fix it cd .. bzr branch work-maria-10.0-base-cassandra-look1 work-maria-10.0-base-cassandra-look1-cp cd work-maria-10.0-base-cassandra-look1-cp # This should show that you're going to merge the dummy change bzr missing --theirs-only ../work-maria-10.0-base-cassandra-look1-r3457/ # # This will will succeed without conflicts. We will use this merge as an # excuse to fix the problem # bzr merge --pull ../work-maria-10.0-base-cassandra-look1-r3457/ # # Now, edit the "broken" file and the original file until sql/sql_join_cache.cc # is ok # gvimdiff ~/home/psergey/dev2/work-maria-10.0-base-cassandra-look1-r3457/sql/sql_join_cache.cc sql/sql_join_cache.cc # Commit bzr gcommit # # Merge the change into a recent 10.0-base. # cd 10.0-base bzr merge --pull ../work-maria-10.0-base-cassandra-look1-cp/ bzr gcommit # # Check the history. It MUST NOT show any of today's merges. # the code in bkah_skip_index_tuple() should show that lines belong to # # igor(a)askmonty.org-20100831163421-iiddbral4jr3q75q # The main patch for MWL#128: Implement Block Nested Loop Hash Join. # # sanja(a)montyprogram.com-20120216064910-k0ud8ja7ef1jnpx4 # Counters for Index Condition Pushdown added (MDEV-130). bzr gannotate sql/sql_join_cache.cc BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 2