- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 3f0b023: MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 3f0b02351a53e0fcaee8554c2c852fb3da8fe7da > parent(s): 5d03dd20a4abbfd9777b619dfd51a6927323955a > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 18:55:38 +0400 > message: > > MDEV-7952 - clock_gettime() takes 0.24% in OLTP RO > > Initialize abs_timeout when it is about to be used. This saves one my_hrtime() > call on hot path (when we acquire MDL lock without waiting). ok > When filling I_S.PROCESSLIST use THD::start_utime/THD::utime_after_query instead > of THD::start_time. This allows us to save 2 clock_gettime() calls. see below > diff --git a/sql/sql_show.cc b/sql/sql_show.cc > index 1e4723d..fa3161a 100644 > --- a/sql/sql_show.cc > +++ b/sql/sql_show.cc > @@ -2730,7 +2730,7 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > TABLE *table= tables->table; > CHARSET_INFO *cs= system_charset_info; > char *user; > - my_hrtime_t unow= my_hrtime(); > + ulonglong unow= microsecond_interval_timer(); > DBUG_ENTER("fill_schema_processlist"); > > DEBUG_SYNC(thd,"fill_schema_processlist_after_unow"); > @@ -2793,9 +2793,12 @@ int fill_schema_processlist(THD* thd, TABLE_LIST* tables, COND* cond) > table->field[4]->store(command_name[tmp->get_command()].str, > command_name[tmp->get_command()].length, cs); > /* MYSQL_TIME */ > - ulonglong start_utime= tmp->start_time * HRTIME_RESOLUTION + tmp->start_time_sec_part; > - ulonglong utime= start_utime && start_utime < unow.val > - ? unow.val - start_utime : 0; > + ulonglong utime= tmp->start_utime; > + ulonglong utime_after_query_snapshot= tmp->utime_after_query; > + if (utime < utime_after_query_snapshot) > + utime= utime_after_query_snapshot; // COM_SLEEP > + utime= utime && utime < unow ? unow - utime : 0; 1. Please add an assert here that utime<=unow. It uses microsecond_interval_timer(), which is supposed to be strictly increasing (unlike my_hrtime()). 2. You might need to update mysqld_list_processes() too. > table->field[5]->store(utime / HRTIME_RESOLUTION, TRUE); > /* STATE */ Regards, Sergei

2 1

Re: [Maria-developers] [Commits] 3d1b65b: MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Apr 28, svoj(a)mariadb.org wrote: > revision-id: 3d1b65b4923a49f9303501dd546af02982608b2b > parent(s): 8a0f3310275f7b4fa445f907140f677910e18999 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-04-28 15:20:48 +0400 > message: > > MDEV-7943 - pthread_getspecific() takes 0.76% in OLTP RO > > Pass THD to find_all_keys() and Item_equal::Item_equal(). > In MRR use table->in_use instead of current_thd. > > This reduces number of pthread_getspecific() calls from 354 to 320. ok to push. although for find_all_keys() it doesn't make any sense, it's a big, complex, and expensive function. One current_thd doesn't change anything. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 2e08ec2: MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO
by Sergei Golubchik 18 Jun '15

18 Jun '15

Hi, Sergey! On Jun 17, svoj(a)mariadb.org wrote: > revision-id: 2e08ec24623e0b3d3db02333e16658dcfaa0535c > parent(s): b776f8d3a8afff55d5f8208da7bdfce9aa33eb39 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-17 13:09:22 +0400 > message: > > MDEV-7956 - handler::rebind_psi() takes 0.07% in OLTP RO > > Do not call handler::rebind_psi() and handler::unbind_psi() when performance > schema is compiled out. > > Overhead change: > handler::rebind_psi 0.04% -> out of radar > handler::unbind_psi 0.03% -> out of radar > open_table 0.21% -> 0.18% > close_thread_table 0.05% -> 0.05% Really? I don't believe it. handler::rebind_psi() and handler::unbind_psi() are empty methods, not doing anything. There's only a cost a virtual function call. And you're saying that it took 15% of the open_table() execution time? Regards, Sergei

2 1

[Maria-developers] [GSoC] MXS-2: Week 2 and 3
by sriram patil 17 Jun '15

17 Jun '15

Hi All, Please find link to my first blog post of second and third week below. <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> MXS-2: Week 2 and 3 <http://srirampatil.tumblr.com/post/121594591925/mxs-2-week-2-and-3> Feel free to point out mistakes, if any. Also, suggestions ans/or reviews are welcome! Thanks, Sriram

2 2

[Maria-developers] GSoC Progress Report [MDEV-5199]
by Blessing Atie 16 Jun '15

16 Jun '15

Hi Sergei, colin! This past week I have studied the sequence engine to understand how it generates tables on the fly. I also looked at how table functions work in other databases. I am currently working on how to implement the simplest table function from our new plugin API(Still to be completed) and which will do exacly what the sequence engine does but this time in a function call like in <select * from udf_seq(1,10)>. Exams are fast approaching in my University. I will acceletrate work as soon as I finish my Exams which will run from 22nd May to 6th June and after which I will be available to the fullest capacity to put enough time on my Work. In the mean while for this week I plan on completing our plugin declaration structure and also look for other candidate functions that can be implemented. Regards, Blessing Atie.

2 1

[Maria-developers] Sprint 10.0: MDEV-8205 timediff returns null when comparing decimal time to time string value
by Alexander Barkov 16 Jun '15

16 Jun '15

Hi Sergei, I'm not sure what to do with this: > MariaDB [test]> select > -> timediff('2014-01-01 00:00:00' , '2014-01-01 01:00:00' ), > -> timediff(20140101000000.000 , 20140101010000.000 ), > -> timediff(20140101000000.000 , '2014-01-01 01:00:00' ), > -> datediff('2014-01-01 00:00:00' , '2014-01-02 01:00:00' ), > -> datediff(20140101000000.000 , 20140102010000.000 ), > -> datediff(20140101000000.000 , '2014-01-02 01:00:00' )\G > *************************** 1. row *************************** > timediff('2014-01-01 00:00:00' , '2014-01-01 01:00:00' ): -01:00:00 > timediff(20140101000000.000 , 20140101010000.000 ): -01:00:00.000 > timediff(20140101000000.000 , '2014-01-01 01:00:00' ): NULL > datediff('2014-01-01 00:00:00' , '2014-01-02 01:00:00' ): -1 > datediff(20140101000000.000 , 20140102010000.000 ): -1 > datediff(20140101000000.000 , '2014-01-02 01:00:00' ): -1 > 1 row in set (0.03 sec) Notice, it returns NULL in one case. The problem is in this piece of the code: > if (args[0]->get_time(&l_time1) || > args[1]->get_time(&l_time2) || > l_time1.time_type != l_time2.time_type) > return (null_value= 1); get_time() forces decimal-to-time conversion to truncate the date part and return MYSQL_TIMESTAMP_TIME. get_time() does not force string-to-time conversion to truncate the date part. It still returns the full MYSQL_TIMESTAMP_DATETIME. I'm afraid a lot of the code rely in this behavior. If we fix string-to-time conversion, mtr will start to fail in other cases. Any ideas what to do?

2 4

[Maria-developers] MDEV-7502 Automatic provisioning of slave – retrieval of data from master
by Martin Kaluznik 16 Jun '15

16 Jun '15

Hello Kristian, after master-slave connection part, I proceeded to retrieval of data from master. There are two types of data which provisioning master will have to send, meta-data and row data. Meta-data For this I found only one method, pass output of SHOW CREATE * to slave in 'Query_log_event'. When I was looking for alternatives, I have found MySQL online backup work log where they are describing similar/same problem under High Level Architecture – Decision ( http://dev.mysql.com/worklog/task/?id=3574 ). Because of this, I find it unlikely, that there currently is better way. Because meta-data retrieval will take only small fraction of provisioning time, I think, that it could be implemented using 'Ed_connection' class, it executes query in string form and returns result set from within replication thread. Disadvantage of this solution is that query has to go through parser and all steps of generic execution, but on the other hand resulting code will be more independent from exact implementations, their pre-conditions and won’t contain any logical mistakes (locking, etc). Row data For this, same method with 'Ed_connection' could work, but it would be probably too big overhead – parser, result processing. So I created low level loop which goes through records of table and fills them in 'Write_rows_log_event'. Could you please check it, if it looks acceptable and I will then rewrite it to generic form, it is provisioning_send_info::send_table_data() function. https://github.com/f4rnham/server/blob/3d36cbfc20dff73d92ce61168dcc9805d68d… Right now it is working as expected on small test case. It goes through whole table at once and creates multiple row events when one would be enough. The same file also contains test of 'Ed_connection' and test of slave being able to receive and process 'Query_log_event'. Thanks for advice, Martin.

2 1

[Maria-developers] Getting the columns from LEX or THD
by sriram patil 16 Jun '15

16 Jun '15

Hi all, I wanted to retrieve a tables columns i.e its schema definition when a query is executed. I figured out LEX and THD structures store these in different variables for different queries. I wanted to get the same when a simple INSERT query is executed, e.g INSERT INTO <table> VALUES(<values>). Where can I find it? Is there any mechanism to get a tables schema that will work for any kind of query? Thanks, Sriram

2 2

Re: [Maria-developers] 8456b23: MDEV-5309 - RENAME TABLE does not check for existence of the table's engine
by Sergei Golubchik 16 Jun '15

16 Jun '15

Hi, Sergey! On Jun 15, svoj(a)mariadb.org wrote: > revision-id: 8456b231e9079be26c77da2a294ea1dac64d9d76 > parent(s): aad8667f8a4e2a26652494b29ee6c12824865ac8 > committer: Sergey Vojtovich > branch nick: mariadb > timestamp: 2015-06-15 15:49:00 +0400 > message: > > MDEV-5309 - RENAME TABLE does not check for existence of the table's engine > > When RENAME TABLE is executed, it apparently does not check whether the engine > is available (unlike ALTER TABLE .. RENAME, which does). It means that if the > engine in question was not loaded on some reason, the table might become > unusable, since the engine won't know about the change. > > With this patch RENAME TABLE fails if storage engine is not available. Ok to push. I'm not completely happy with the "table does not exist" error in this case, but I suspect that doing something reasonable might be not very easy. And it's a corner case anyway. Regards, Sergei

2 1

[Maria-developers] unsubscribe
by Abdul Hakeem 14 Jun '15

14 Jun '15

2 1