- developers - lists.mariadb.org

Re: [Maria-developers] [GSoC] self-tuning optimizer
by Sergei Golubchik 13 Jun '14

13 Jun '14

Hi, Anshu! On Jun 13, Anshu Avinash wrote: > > So I have refactored Cost_factors::init() into Cost_factors::init() and > Cost_factors::re_init(). The diff is at: > https://github.com/igniting/server/commit/41e360309c067d072d788495e4e948054… Looks great. I've added one comment there. > I had started writing a test for checking whether if loading a new > storage engine works or not. I loaded 'Example' storage engine, but > was unable to test the current t1 table on it, as t1 contains a > primary key. Also I need to write test cases for 'time_for_compare'. > Any hints on that? Hm. Yes. Example engine, is pretty useless for you, as you cannot create tables in it. You can use InnoDB plugin. But create a separate test file for that. For example (I'll use the short name below, don't commit it): a.test: ============================================== if (!$HA_INNODB_SO) { skip Need InnoDB plugin; } install plugin innodb soname 'ha_innodb'; ... do your tests here uninstall plugin innodb; ============================================== you will also need a.opt file: ============================================== --ignore-builtin-innodb --loose-innodb ============================================== As for time_for_compare... Here's a universal approach, you can do it yourself. This time_for_compare is 5 by default, right? Change it to be, say, 500, and run existing tests (start from the main suite, and there from optimizer tests, e.g. from select.test). If some test will fail - here's your query, extract it, simplify, perhaps, and put in your test file. That's exactly what I just did :) And here's a simple test: create table t1 (a blob, index(a(20))); create table t2 (a blob, index(a(20))); insert into t1 values ('one'),('two'),('three'),('four'),('five'); insert into t2 values ('one'),('two'),('three'),('four'),('five'); insert into t2 values ('one'),('two'),('three'),('four'),('five'); drop table t1, t2; Perhaps you can get it down to one table - I didn't try. > Also I think I can start with the next part, i.e. collect statistics. We > can have a structure like: > > struct Cost_factor_stats > { > char *cost_factor_name; > double cost_factor_value; > double total_queries; total_queries should be ulonglong, not double. > double total_query_time; > double total_query_time_squared; > }; > > We will be updating these structures after every query per THD and write > the data into a persistent table on disconnect. Is this workflow correct? Almost. You need a Cost_factor_stats structure per cost factor (and per engine where appropriate). You don't need the name there. You have these structures per THD and globally. Basically, instead of your current double time_for_compare_val; you will have Cost_factor_stats time_for_compare_val; hmm, perhaps better to name the structure simply "Cost_factor": Cost_factor time_for_compare; And you put them all in one structure: struct Engine_cost_factors { Cost_factor read_time; Cost_factor scan_time; }; struct Global_cost_factors { Cost_factor time_for_compare; Cost_factor time_for_compare_rowid; }; class Cost_factors { Global_cost_factors global; Engine_cost_factors engine[MAX_HA]; double time_for_compare() const { return global.read_time.value; } double time_for_compare_rowid() const; double read_time(const handler*) const; double scan_time(const handler*) const; }; Now, you stick this structure in the THD, and also declare one instance globally. On connect you initialize THD::Cost_factor values from the global Cost_factor object. On disconnect you add THD::Cost_factor values back to the global Cost_factor object. There's no writing to disk so far, we'll think about it later (you don't want to write to disk on *every* disconnect). > Few more questions: > 1.What will we do if the query had used more than one cost factor? > 2.How would joins be handled? Yes, a query will certainly use more than one cost factor. In fact, this is something we might want to experiment with. I see two approaches - exact and approximate. Approximate one is described in MDEV. Say, you've counted 500 index reads, 20,000 sequential row reads (table scan), some 10,000,000 comparisons, etc. And you know how long the query took. For another query you've counted different numbers, and so on. Basically, you'll have a system of linear equations that one can solve to know how the time was split. The problem with this approach - the server is doing much more than purely index reads, table scans, and comparisons. So this unaccounted time will be split between cost factors. I don't know if it's a problem. The exact approach - we only measure times spent on the actual operation. Basically, you measure how long *each row read* took, how long *each index read* took, etc. This will show no unaccounted time. But it's more expensive, it might be too expensive to be practically useful - I don't know that. These two approaches need different data structures, the first one needs more memory, because you cannot start aggregating before you solve the system of equations. Basically, if you have four constant (time_for_compare, time_for_compare_rowid, read_time, scan_time, only one engine), you'll need four equations, that is, per THD you need to store four measurements: struct measurement { ulong time_for_compare; ulong time_for_compare_rowid; struct per_engine { ulong scan_time; ulong read_time; } per_engine[MAX_HA]; double total_time; }; and in THD you need struct measurement data[4]; Also, note that I'm writing per_engine[MAX_HA], but it's a simplification, good enough for a prototype. But in the final code we cannot allocate that much memory per THD, as most of the time we'll have only few engines, not MAX_HA. Regards, Sergei

1 0

[Maria-developers] WebScaleSQL: Adjust linking flags to not embed some libs
by Sergey Vojtovich 13 Jun '14

13 Jun '14

Hi Sergei, during our recent discussion re WebScaleSQL patches we agreed to accept $subj: https://github.com/webscalesql/webscalesql-5.6/commit/361e3b83145402945b737… I studied our binaries and it looks like we embed zlib and ssl libraries only if WITH_ZLIB=bundled/WITH_SSL=bundled. E.g. DEB/RPM packages use system libs and do not embed zlib/ssl, whereas tarball uses bundled zlib/yassl and embeds them. Not embedding yassl into the client library will make the latter almost useless. Same probably applies to zlib even though it is normally offered by OS-es. Said the above I believe our build scripts behave properly and we should skip this patch. What's your take? Regards, Sergey

2 1

[Maria-developers] Java Connector Coding till 12th June
by Puneet Dewan 13 Jun '14

13 Jun '14

Hi Everyone, This week, I was able to send the com_stmt_execute command from the *Driver * in the way it is accepted by the MariaDB server So, Now I am able to insert a row in the database using com_stmt_execute command. But from the console when I try to see the values I see *NULL* I used *Wireshark* to capture the packets,but I can see the value(Varchar /Int/..etc) is passed in the packet which wireshark captures. I am investigating the code but could not find anything till now. In Wireshark it shows* [Expert Info (warn/undecoded) :FIXME: Excute Dissector Incomplete]* Now I think I am not sending the values in a correct format.Will look and try to resolve it. Regards Puneet. On Thu, Jun 5, 2014 at 10:42 PM, Puneet Dewan <puneetd30(a)gmail.com> wrote: > Hi Everyone, > > The work done till 5th June: > 1.I started studying the connector immediately after my semester exams got > over(5th May). > 2. Understood the relationship between different classes. > 3.Read the MySql documentation for text protocol and map the commands from > documentation onto code.This thing gave a clear idea about how things are > moving from client to server. > 4.Setup the code on Ubuntu using eclipse and tested against database. > Setup the Team branch in launchpad. > 5.Debug the test classes to see how different classes are interlinked and > understood that MySQLProtocol.java is the heart of our JDBC driver. > 6.Then I started reading Client Server Protocol documentation i.e > ServerSide prepared statement and try to see how and where I have to code > it. > 7.Then I saw that there is a class MySqlServerSidePreparedStatement.java, > Initially I coded the prepareStatement() ,close(),and execute() in that > class seperately. > But after (Code review) discussion with Massimo, we donot need to use that > class. > Instead use MySqlPreparedStatement.java to do the same work.So made > changes accordingly. > 8.I had pushed some of the code which I have written to launchpad and > discussed with Massimo last week. > 9.Last week I was struck with Wireshark on windows and ubuntu both. > I was unable to see the packets going to database and seeing the response. > 10.On Monday the problem was resolved as I was using the wrong interface.I > should have used loopback.io(127.0.0.1) instead on ubuntu(thanks to > Georg). > Unfortunately the thing does not work on windows.Tried a lot many times. > 11.Now I am working on the execute method of client server protocol as I > am getting exception while using that method.Wireshark is playing a great > role in how the packets are flowing. > > From now I will do weekly blogging and keep everyone updated. > > Thanks & Regards > Puneet. >

1 0

[Maria-developers] Allow to turn off max_connect_errors
by Honza Horak 13 Jun '14

13 Jun '14

Hi guys, there are apparently some tools out there [1], that check if the server is up quite often, while not closing the connection properly. It eventually ends in 'many connection errors', because max_connect_errors is always limited now. I understand that this way of checking may be wrong, but there may be scenarios where we do not want to check for `max_connect_errors` at all. So, would it be acceptable for mariadb to change behaviour of max_connect_errors option, so that it accepts also 0 as a possible value, which would mean 'do not check connect errors at all'? I'm bringing the idea here first, but will submit a report and possibly patch if it does not seem to be undesired behaviour. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1104957 TIA and regards, Honza

4 4

Re: [Maria-developers] [Commits] Rev 4018: MDEV-4784 - merge test cases from 5.6 in lp:maria/10.0
by Sergei Golubchik 12 Jun '14

12 Jun '14

Hi, Sergey! > === added file 'mysql-test/include/have_daemon_example_plugin.inc' > --- a/mysql-test/include/have_daemon_example_plugin.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/have_daemon_example_plugin.inc 2014-04-14 09:20:24 +0000 > @@ -0,0 +1,16 @@ > +disable_query_log; > +# > +# Check if server has support for loading plugins > +# > +if (`SELECT @@have_dynamic_loading != 'YES'`) { > + --skip daemon example plugin requires dynamic loading > +} > + > +# > +# Check if the variable DAEMONEXAMPLE is set > +# > +if (!$LIBDAEMON_EXAMPLE_SO) { > + --skip daemon_example plugin requires the environment variable \$DAEMONEXAMPLE to be set (normally done by mtr) Eh? It was in your first patch. I thought it's an additional patch, but it looks like it includes the first one? Okay, I will copy all my comments from the first patch here to have a complete review in one email. So, here I said ************************ it's always done by mtr, a better error message should be "No libdaemon_example.so was found" or simply "Need daemon_example plugin" and, btw, the first if() is redundant, if no dynamic loading was enabled no dynamic plugins will be built whatsoever. > +} > + > +enable_query_log; > > === added file 'mysql-test/include/ib_logfile_size_check.inc' > --- a/mysql-test/include/ib_logfile_size_check.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/ib_logfile_size_check.inc 2014-04-14 09:20:24 +0000 > @@ -0,0 +1,14 @@ I'm not a great fan of obscure include files that are only used once in one single test. Perhaps it's better to inline it? > +perl; > + my $dir = $ENV{'MYSQLD_DATADIR'}; > + my $size; > + opendir(DIR, $dir) or die $!; > + while (my $file = readdir(DIR)) > + { > + > + next unless ($file =~ m/\ib_logfile.$/); > + $size = -s "$dir/$file"; > + print "The size of the ib_logfile(0/1): $size \n"; > + } > + close(DIR); > + exit(0) > +EOF > > === added file 'mysql-test/include/vardir_size_check.inc' > --- a/mysql-test/include/vardir_size_check.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/vardir_size_check.inc 2014-04-14 09:20:24 +0000 > @@ -0,0 +1,26 @@ Same here. Although it's worse than with the previous file :) ib_logfile_size_check.inc is only used in innodb_log_file_size_functionality.test. This file - too. But in 5.6 this one is also used in query_cache_type_functionality, table_open_cache_functionality, and table_definition_cache_functionality, sort_buffer_size_functionality, query_cache_size_functionality. I suppose somebody just copied innodb_log_file_size_functionality over and edited it. I don't see why would anyone really want to check the vardir size in all these other tests. So, yes, better to inline this file too, to avoid silly mistakes like that. > +--echo Check the size of the vardir > +--echo The output size is in unit blocks > +perl; > +#!/usr/bin/perl > +use warnings; > +use strict; > +use File::Find; > +my $dir = $ENV{'MYSQLTEST_VARDIR'}; > +my $size = 0; > +find( sub { $size += -f $_ ? -s _ : 0 }, $dir ); > + > +if ( $size < 1717987000 ) > + { print "TRUE", "\n";} > +else > + { print "FALSE $size", "\n";} > + > + > +## Expected size for the VAR dir being changed for the PB2 runs > + > +##if ( $size =~ /^496[\d]{5}$/ ) > +## { > +## { print "TRUE", "\n";} > +## } > +##else > +## { print "FALSE $size", "\n";} > +EOF > > === modified file 'mysql-test/mysql-test-run.pl' > --- a/mysql-test/mysql-test-run.pl 2014-02-26 14:28:07 +0000 > +++ b/mysql-test/mysql-test-run.pl 2014-04-14 09:20:24 +0000 > @@ -5350,6 +5350,14 @@ sub mysqld_arguments ($$$) { > mtr_add_arg($args, "--gdb"); > } > > + # Enable the debug sync facility, set default wait timeout. > + # Facility stays disabled if timeout value is zero. > + mtr_add_arg($args, "--loose-debug-sync-timeout=%s", > + $opt_debug_sync_timeout) unless $opt_user_args; Why was it moved? > + > + # Options specified in .opt files should be added last so they can > + # override defaults above. > + > my $found_skip_core= 0; > foreach my $arg ( @$extra_opts ) > { > === added file 'mysql-test/suite/archive/archive_no_symlink-master.opt' > --- a/mysql-test/suite/archive/archive_no_symlink-master.opt 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/archive/archive_no_symlink-master.opt 2014-04-14 09:20:24 +0000 > @@ -0,0 +1 @@ > +--skip-symbolic-links just fyi: in MariaDB the file name can simply be archive_no_symlink.opt -master and -slave are only needed for replication tests to have different options for the master and the slave. > > === added file 'mysql-test/t/bug12969156.test' > --- a/mysql-test/t/bug12969156.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/bug12969156.test 2014-04-14 09:20:24 +0000 > @@ -0,0 +1,18 @@ > +--source include/have_daemon_example_plugin.inc > +--source include/not_embedded.inc > +# TODO: the windows emulation of pthreads doesn't behave predictably > +--source include/not_windows.inc > + > +--echo # > +--echo # Bug #12969156 : SEGMENTATION FAULT ON UNINSTALLING > +--echo # DAEMON_EXAMPLE PLUGIN > +--echo # > + > +let $counter= 0; > +while ($counter < 10) > +{ > +--replace_result $LIBDAEMON_EXAMPLE_SO DAEMONEXAMPLE > + eval INSTALL PLUGIN daemon_example SONAME '$LIBDAEMON_EXAMPLE_SO'; in our own tests (not copied from 5.6) better use install soname 'libdaemon_example'; it's shorter, doesn't need --eval and doesn't need --replace_result > + UNINSTALL PLUGIN daemon_example; > + inc $counter; > +} > > === added file 'mysql-test/t/innodb_log_file_size_functionality.test' > --- a/mysql-test/t/innodb_log_file_size_functionality.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/innodb_log_file_size_functionality.test 2014-04-14 09:20:24 +0000 > @@ -0,0 +1,124 @@ This should be renamed to sys_vars.innodb_log_file_size_func test > +############################################################################### > +# # > +# Variable Name: innodb_log_file_size # > +# Scope: Global # > +# Access Type: Static # > +# Data Type: numeric # > +# # > +# # > +# Creation Date: 2012-08-20 # > +# Author : Tanjot Singh Uppal # > +# # > +# # > +# Description:Test Cases of Static System Variable innodb_log_file_size # > +# that checks the behavior of this variable in the following ways # > +# * Value Check # > +# * Scope Check # > +# * Functionality Check # > +# * Accessability Check # > +# # > +# This test does not perform the crash recovery on this variable # > +# For crash recovery test on default change please run the ibtest # > +############################################################################### Regards, Sergei

1 0

Re: [Maria-developers] [Commits] Rev 4018: MDEV-4784 - merge test cases from 5.6 in lp:maria/10.0
by Sergei Golubchik 12 Jun '14

12 Jun '14

Hi, Sergey! > === added file 'mysql-test/include/have_daemon_example_plugin.inc' > --- a/mysql-test/include/have_daemon_example_plugin.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/have_daemon_example_plugin.inc 2014-03-11 09:28:16 +0000 > @@ -0,0 +1,16 @@ > +disable_query_log; > +# > +# Check if server has support for loading plugins > +# > +if (`SELECT @@have_dynamic_loading != 'YES'`) { > + --skip daemon example plugin requires dynamic loading > +} > + > +# > +# Check if the variable DAEMONEXAMPLE is set > +# > +if (!$LIBDAEMON_EXAMPLE_SO) { > + --skip daemon_example plugin requires the environment variable \$DAEMONEXAMPLE to be set (normally done by mtr) it's always done by mtr (not just "normally"). So a better error message should be "No libdaemon_example.so was found" or simply "Need daemon_example plugin" and, btw, the first if() is redundant, if no dynamic loading was enabled no dynamic plugins will be built whatsoever. > +} > + > +enable_query_log; > > === added file 'mysql-test/include/ib_logfile_size_check.inc' > --- a/mysql-test/include/ib_logfile_size_check.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/ib_logfile_size_check.inc 2014-03-11 09:28:16 +0000 > @@ -0,0 +1,14 @@ I'm not a great fan of obscure include files that are only used once in one single test. Perhaps it's better to inline it? > +perl; > + my $dir = $ENV{'MYSQLD_DATADIR'}; > + my $size; > + opendir(DIR, $dir) or die $!; > + while (my $file = readdir(DIR)) > + { > + > + next unless ($file =~ m/\ib_logfile.$/); > + $size = -s "$dir/$file"; > + print "The size of the ib_logfile(0/1): $size \n"; > + } > + close(DIR); > + exit(0) > +EOF > > === added file 'mysql-test/include/vardir_size_check.inc' > --- a/mysql-test/include/vardir_size_check.inc 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/include/vardir_size_check.inc 2014-03-11 09:28:16 +0000 > @@ -0,0 +1,26 @@ Same here. Although it's worse than with the previous file :) ib_logfile_size_check.inc is only used in innodb_log_file_size_functionality.test. This file - too. But in 5.6 this one is also used in query_cache_type_functionality, table_open_cache_functionality, and table_definition_cache_functionality, sort_buffer_size_functionality, query_cache_size_functionality. I suppose somebody just copied innodb_log_file_size_functionality over and edited it without much thinking. I don't see why would anyone really want to check the vardir size in all these other tests. So, yes, better to inline this file too, to avoid silly mistakes like that. > +--echo Check the size of the vardir > +--echo The output size is in unit blocks > +perl; > +#!/usr/bin/perl > +use warnings; > +use strict; > +use File::Find; > +my $dir = $ENV{'MYSQLTEST_VARDIR'}; > +my $size = 0; > +find( sub { $size += -f $_ ? -s _ : 0 }, $dir ); > + > +if ( $size < 1717987000 ) > + { print "TRUE", "\n";} > +else > + { print "FALSE $size", "\n";} > + > + > +## Expected size for the VAR dir being changed for the PB2 runs > + > +##if ( $size =~ /^496[\d]{5}$/ ) > +## { > +## { print "TRUE", "\n";} > +## } > +##else > +## { print "FALSE $size", "\n";} > +EOF > > === added file 'mysql-test/suite/archive/archive_no_symlink-master.opt' > --- a/mysql-test/suite/archive/archive_no_symlink-master.opt 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/archive/archive_no_symlink-master.opt 2014-03-11 09:28:16 +0000 > @@ -0,0 +1 @@ just fyi: in MariaDB the file name can simply be archive_no_symlink.opt -master and -slave are only needed for replication tests to have different options for the master and the slave. > +--skip-symbolic-links > > === added file 'mysql-test/t/bug12969156.test' > --- a/mysql-test/t/bug12969156.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/bug12969156.test 2014-03-11 09:28:16 +0000 > @@ -0,0 +1,18 @@ > +--source include/have_daemon_example_plugin.inc > +--source include/not_embedded.inc > +# TODO: the windows emulation of pthreads doesn't behave predictably > +--source include/not_windows.inc > + > +--echo # > +--echo # Bug #12969156 : SEGMENTATION FAULT ON UNINSTALLING > +--echo # DAEMON_EXAMPLE PLUGIN > +--echo # > + > +let $counter= 0; > +while ($counter < 10) > +{ > +--replace_result $LIBDAEMON_EXAMPLE_SO DAEMONEXAMPLE > + eval INSTALL PLUGIN daemon_example SONAME '$LIBDAEMON_EXAMPLE_SO'; in our own tests (not copied from 5.6) better use install soname 'libdaemon_example'; it's shorter, doesn't need --eval and doesn't need --replace_result > + UNINSTALL PLUGIN daemon_example; > + inc $counter; > +} > > === added file 'mysql-test/t/innodb_log_file_size_functionality.test' > --- a/mysql-test/t/innodb_log_file_size_functionality.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/innodb_log_file_size_functionality.test 2014-03-11 09:28:16 +0000 > @@ -0,0 +1,124 @@ This should be renamed to sys_vars.innodb_log_file_size_func test > +############################################################################### > +# # > +# Variable Name: innodb_log_file_size # > +# Scope: Global # > +# Access Type: Static # > +# Data Type: numeric # > +# # > +# # > +# Creation Date: 2012-08-20 # > +# Author : Tanjot Singh Uppal # > +# # > +# # > +# Description:Test Cases of Static System Variable innodb_log_file_size # > +# that checks the behavior of this variable in the following ways # > +# * Value Check # > +# * Scope Check # > +# * Functionality Check # > +# * Accessability Check # > +# # > +# This test does not perform the crash recovery on this variable # > +# For crash recovery test on default change please run the ibtest # > +############################################################################### > + > +-- source include/have_innodb.inc > +-- source include/not_embedded.inc > +-- source include/have_innodb_16k.inc > + > +echo '#________________________VAR_09_INNODB_LOG_FILE_SIZE__________________#' > +echo '##' > +--echo '#---------------------WL6372_VAR_9_01----------------------#' > +#################################################################### > +# Checking default value # > +#################################################################### > +SELECT COUNT(@@GLOBAL.innodb_log_file_size); > +--echo 1 Expected > + > +SELECT @@GLOBAL.innodb_log_file_size; > +--echo 5242880 Expected > + > + > + > +--echo '#---------------------WL6372_VAR_9_02----------------------#' > +#################################################################### > +# Checking Value can be set - Static # > +#################################################################### > +--error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SET @@local.innodb_log_file_size=1; > +--echo Expected error 'Read only variable' > + > +--error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SET @@session.innodb_log_file_size=1; > +--echo Expected error 'Read only variable' > + > +--error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SET @@GLOBAL.innodb_log_file_size=1; > +--echo Expected error 'Read only variable' > + > +--error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SET @@GLOBAL.innodb_log_file_size=DEFAULT; > +--echo Expected error 'Read only variable' > + > +SELECT COUNT(@@GLOBAL.innodb_log_file_size); > +--echo 1 Expected > + > + > + > +--echo '#---------------------WL6372_VAR_9_03----------------------#' > +################################################################# > +# Check if the value in GLOBAL Table matches value in variable # > +################################################################# > +SELECT @@GLOBAL.innodb_log_file_size = VARIABLE_VALUE > +FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES > +WHERE VARIABLE_NAME='innodb_log_file_size'; > +--echo 1 Expected > + > +SELECT COUNT(@@GLOBAL.innodb_log_file_size); > +--echo 1 Expected > + > +SELECT COUNT(VARIABLE_VALUE) > +FROM INFORMATION_SCHEMA.GLOBAL_VARIABLES > +WHERE VARIABLE_NAME='innodb_log_file_size'; > +--echo 1 Expected > + > + > + > +--echo '#---------------------WL6372_VAR_9_04----------------------#' > +################################################################################ > +# Checking Variable Scope # > +################################################################################ > +SELECT @@innodb_log_file_size = @@GLOBAL.innodb_log_file_size; > +--echo 1 Expected > + > +--Error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SELECT COUNT(@@local.innodb_log_file_size); > +--echo Expected error 'Variable is a GLOBAL variable' > + > +--Error ER_INCORRECT_GLOBAL_LOCAL_VAR > +SELECT COUNT(@@SESSION.innodb_log_file_size); > +--echo Expected error 'Variable is a GLOBAL variable' > + > +SELECT COUNT(@@GLOBAL.innodb_log_file_size); > +--echo 1 Expected > + > +--Error ER_BAD_FIELD_ERROR > +SELECT innodb_log_file_size = @@SESSION.innodb_log_file_size; > +--echo Expected error 'Unknown column innodb_log_file_size in field list' > + > + > + > +--echo '#---------------------WL6372_VAR_9_05----------------------#' > +############################################################################### > +# Checking the /Var directory size # > +############################################################################### > +-- source include/vardir_size_check.inc > +--echo TRUE Expected > + > +--echo '#---------------------WL6372_VAR_9_06----------------------#' > +################################################################################# > +# Checking the size of ib_logfile # > +################################################################################# > +let MYSQLD_DATADIR=`SELECT @@datadir`; > +--source include/ib_logfile_size_check.inc > +--echo 5242880 expected > + > Regards, Sergei

1 0

[Maria-developers] PERFORMANCE_SCHEMA to be disabled in 10.0 (10.0.12)
by Colin Charles 12 Jun '14

12 Jun '14

Hi all, Recently there was chat about how PERFORMANCE_SCHEMA was enabled by mistake and it should be disabled in the 10.0 series. I'm curious - how many of you are using PERFORMANCE_SCHEMA? Is it a problem to turn it on, if you use it? I'm referring to: https://mariadb.atlassian.net/browse/MDEV-6249 Looking from the webscalesql list, there are examples of performance degradation: https://groups.google.com/d/msg/webscalesql/B-4bPIb8mHI/eUNsl0lSfbMJ https://groups.google.com/d/msg/webscalesql/B-4bPIb8mHI/-YZMMCuPw3QJ quote: "Our perf testing agrees with your assessment (we see about a 5%-6% perf hit when it's included and on, and a 2%-3% hit when it's included but off)" Please discuss this, either here or on MDEV-6249 Thanks cheers, -colin -- Colin Charles, Chief Evangelist, SkySQL - The MariaDB Company blog: http://bytebot.net/blog/| t: +6-012-204-3201 | Skype: colincharles

6 10

[Maria-developers] Extendet FederatedX storage engine to support updating Sphinx RT indexes
by Markus Lidel 12 Jun '14

12 Jun '14

Hello, the Sphinx Search engine has RT indexes, which could be updated with a subset of SQL commands, refered to as SphinxQL: http://sphinxsearch.com/docs/2.1.1/sphinxql-reference.html Because the FederatedX storage engine uses some commands, which Sphinx does not know, here is a patch, wich extends the FederatedX storage engine to support this subset of commands. Now its possible to update Sphinx RT indexes directly from MariaDB. To create a connection to the RT index in the Sphinx default RT-index: index rt { type = rt path = @CONFDIR@/data/rt rt_field = title rt_field = content rt_attr_string = title rt_attr_string = content rt_attr_uint = gid } you just have to call: CREATE TABLE `rt` ( `id` BIGINT UNSIGNED NOT NULL, `title` TEXT, `content` TEXT, `gid` INT UNSIGNED ) ENGINE=FEDERATED CONNECTION='sphinxql://root@localhost:9306/rt'; It would be great, if the attached patch could be integrated into MariaDB. If you have any suggestions, please feel free to contact me. Best regards, Markus Lidel

4 8

Re: [Maria-developers] [GSoC] Accepted student ready to work : )
by Pablo Estrada 10 Jun '14

10 Jun '14

Hello all, I'm still interested on a call, (I would make sure to write down everything as part of an email to keep it clearly organized here), but as Elena suggested, I'll try to look at Sergei's bzr repo first, and all the documentation. In any case, I already have a decent idea of how the data is arranged. I can see how it is difficult to trace test results back to code changes directly, but it might be possible. I still haven't figured out how to recognize what code changes pertain to the same 'history', or 'line' (I think that you were not considering this in your experiments... and it might turn out to not be relevant at all, but I still want to consider it, to try to make a more complete model). So I have just two questions that should be easy to answer by email: 1. In your graphs, exactly, what do you mean by Precision? What about Recall? And cutoff? 2. I looked at your launchpad profile but I can't seem to find the repo with your tests (if you even pushed it to lp at all). Is it available? That's it for today : ) Until next time. Pablo On Thu, Apr 24, 2014 at 12:28 AM, Sergei Golubchik <serg(a)skysql.com> wrote: > On April 23, 2014 10:07:23 AM CEST, Pablo Estrada wrote: > > >If it's not too inconvenient, do you think we could set up a Google > >Hangout > >or a Skype call on Monday to go over a few questions quickly? > > > Definitely. This week I'm on vacations and without a laptop, back home on > Sunday. So, Monday is fine. But please if you have specific questions - ask > them now in emails. I'll prepare answers for Monday, but it'll take time to > remember everything. That is, if you will wait with questions till the > call, I might not be able to remember the answer on the spot. > Regards, > Sergei >

4 17

Re: [Maria-developers] Rev 4234: Fixed bug mdev-6071
by Sergei Golubchik 10 Jun '14

10 Jun '14

Hi, Igor! On Jun 09, Igor Babaev wrote: > revno: 4234 > revision-id: igor(a)askmonty.org-20140610050716-0x8xaquf3itvofjc > parent: bar(a)mariadb.org-20140606062952-x2jwt4mgrgr6tpw6 > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-10.0-bugs > timestamp: Mon 2014-06-09 22:07:16 -0700 > message: > Fixed bug mdev-6071. > The method JOIN_CACHE::init may fail (return 1) if some conditions on the > used join buffer is not satisfied. For example it fails if join_buffer_size > is greater than join_buffer_space_limit. The conditions should be checked > when running the EXPLAIN command for the query. That's why the method > JOIN_CACHE::init has to be called for EXPLAIN commands as well. It's an improvement over the old behavior - as EXPLAIN shows correctly whether BKA is used. But I think there's still not enough diagnostics. In the bug report Sergey wrote that " I think it's a big gotcha that @join_buffer_size must be lower than @@join_buffer_space_limit when optimizer_space_limit optimization is off. " So, I'd believe users will be very confused that in some cases BKA is suddenly turned off, when they expect it to be used. Of course, without this bugfix they would've not even noticed that, which is even worse. So, this bugfix is good. But it would be nice to have some kind of an explanation of why BKA is not used. At the very least in the manual. Better - here as a warning, like if (for_explain) push_warning("BKA was not used because ..."; goto fail; > === modified file 'sql/sql_select.cc' > --- a/sql/sql_select.cc 2014-06-05 22:07:27 +0000 > +++ b/sql/sql_select.cc 2014-06-10 05:07:16 +0000 > @@ -10541,7 +10541,7 @@ > if (cache_level == 1) > prev_cache= 0; > if ((tab->cache= new JOIN_CACHE_BNL(join, tab, prev_cache)) && > - ((options & SELECT_DESCRIBE) || !tab->cache->init())) > + !tab->cache->init(MY_TEST(options & SELECT_DESCRIBE))) MY_TEST here (and in other similar places) is redundant, you could've simply written !tab->cache->init(options & SELECT_DESCRIBE)) > { > tab->icp_other_tables_ok= FALSE; > return (2 - MY_TEST(!prev_cache)); and while it wasn't part of your bug fix, I cannot help but noticing that MY_TEST() is redundant here too. !prev_cache is boolean, it's always 0 or 1. Regards, Sergei

1 0