March 2013 - developers - lists.mariadb.org

[Maria-developers] impact of segmented table_open_cache on sysbench results
by Axel Schwenke 16 Mar '13

16 Mar '13

Hi, I have been running a sysbench on recent 5.5, 5.6 and 10.0 releases with tuning a'la Dimitri K. There is one feature that is only in MySQL-5.6.10: table_open_cache_instances = 16 and I wondered how it would affect the sysbench result. It makes a *huge* difference. For the curious I also add the result from a previous run that shows the impact of tcmalloc vs. glibc malloc. Disclaimer: hardware is 64 cores (32 w/o HT) XL

2 3

[Maria-developers] mariadb++
by Sylvain Rochette 14 Mar '13

14 Mar '13

I just want to inform that the last few weeks I worked on a new open source project called mariadb++. It's use mariadb-native-client lib, it an alternative over MySQL++/MySQL connector. It's available here: https://launchpad.net/mariadb++ Regards, Sylvain Rochette

2 1

Re: [Maria-developers] [Commits] Rev 3697: MDEV-4272 fix. in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-4272/
by Sergei Golubchik 14 Mar '13

14 Mar '13

Hi, Sanja! The idea of the fix is correct. See a couple of comments below. On Mar 14, sanja(a)askmonty.org wrote: > message: > MDEV-4272 fix. > > Incorrect NULL value handling in Item_func_conv_charset fixed. > === modified file 'sql/item_strfunc.cc' > --- a/sql/item_strfunc.cc 2013-01-28 12:36:05 +0000 > +++ b/sql/item_strfunc.cc 2013-03-14 13:22:32 +0000 > @@ -2987,7 +2987,7 @@ String *Item_func_conv_charset::val_str( > return null_value ? 0 : &str_value; > String *arg= args[0]->val_str(str); > uint dummy_errors; > - if (!arg) > + if (!arg || args[0]->null_value) it's redundant. One of these conditions is enough, no need to check both. > { > null_value=1; > return 0; > > === modified file 'sql/item_strfunc.h' > --- a/sql/item_strfunc.h 2013-01-15 18:07:46 +0000 > +++ b/sql/item_strfunc.h 2013-03-14 13:22:32 +0000 > @@ -859,25 +859,45 @@ public: > { > if (args[0]->result_type() == STRING_RESULT) > return Item_str_func::val_int(); > - return args[0]->val_int(); > + { > + longlong res= args[0]->val_int(); > + if ((null_value= args[0]->null_value)) > + return 0; > + return res; > + } Why did you add an extra pair of curly brackets? it's also redundant. Regards, Sergei

1 0

[Maria-developers] accelerating CREATE TABLE
by Toshikuni Fukaya 13 Mar '13

13 Mar '13

Hi, I made a patch to accelerate CREATE TABLE on the innodb plugin. To zero table spaces, I used fallocate instead of normal writes and sync. I compared MariaDB 5.5 trunk and the patched one by our own application, which creates > 1000 tables in series, with ext4 filesystem on Ubuntu 12.04. Results are shown below. Original MariaDB 5.5 trunk: 64.9 seconds (5 times avg.) Patched MariaDB 5.5 trunk: 36.0 seconds (5 times avg.) Any comments or suggestions? Thanks, Toshikuni Fukaya

3 8

[Maria-developers] MariaDB 5.5.30 Release Prep
by Daniel Bartholomew 12 Mar '13

12 Mar '13

All, I've prepped changelog and release notes pages for MariaDB 5.5.30. https://kb.askmonty.org/en/mariadb-5530-release-notes/ https://kb.askmonty.org/en/mariadb-5530-changelog/ If there is anything I should be sure to mention in the release notes, please let me know ASAP. Unless something comes up, I plan on activating and announcing the release tomorrow (12 Mar 2013). Thanks. -- Daniel Bartholomew Google+ - http://gplus.to/dbart Twitter - http://twitter.com/daniel_bart MariaDB: An Enhanced Drop-in Replacement for MySQL Website - http://mariadb.org Twitter - http://twitter.com/mariadb Google+ - http://google.com/+mariadb Facebook - http://fb.com/MariaDB.dbms Knowledgebase - http://kb.askmonty.org Monty Program - http://montyprogram.com

1 0

[Maria-developers] issue with Index Condition Pushdown in MariaDB 5.5.28a
by Zardosht Kasheff 11 Mar '13

11 Mar '13

Hello, I have found an interesting issue with index condition pushdown. I do not know if it is a bug, or if I am misusing the feature. I have found that in one scenario, when performing a join, an index condition is pushed down, but because handler->end_range is not set, handler_index_cond_check never returns ICP_OUT_OF_RANGE, even though we are out of range. Here is the relevant stack trace, I cannot yet send the entire trace as it may include customer information, and I need to double check it is ok to send: #15 0x00002aaac4f33593 in ha_tokudb::index_next_same (this=0x2fb33d8, buf=0x2fb53b8 "\302\177\254\353/\036", key=0x31b36d0 "Y\001", keylen=395) ---Type <return> to continue, or q <return> to quit--- at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/storage/tokudb/ha_tokudb.cc:4768 #16 0x00000000005e782c in handler::ha_index_next_same (this=0x2fb33d8, buf=0x2fb53b8 "\302\177\254\353/\036", key=0x31b36d0 "Y\001", keylen=395) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_class.h:4246 #17 0x000000000065d103 in join_read_next_same (info=0x31b2f68) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16929 #18 0x000000000065b54a in sub_select (join=0x319f588, join_tab=0x31b2eb8, end_of_records=false) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16142 #19 0x000000000065bb5f in evaluate_join_record (join=0x319f588, join_tab=0x31b2b98, error=0) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16342 #20 0x000000000065b628 in sub_select (join=0x319f588, join_tab=0x31b2b98, end_of_records=false) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16162 #21 0x000000000065bb5f in evaluate_join_record (join=0x319f588, join_tab=0x31b2878, error=0) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16342 #22 0x000000000065b498 in sub_select (join=0x319f588, join_tab=0x31b2878, end_of_records=false) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16123 #23 0x000000000065bb5f in evaluate_join_record (join=0x319f588, join_tab=0x31b2558, error=0) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16342 #24 0x000000000065b628 in sub_select (join=0x319f588, join_tab=0x31b2558, end_of_records=false) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:16162 #25 0x000000000065ad52 in do_select (join=0x319f588, fields=0x0, table=0x31bf368, procedure=0x0) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:15793 #26 0x0000000000639c5d in JOIN::exec (this=0x319f588) at /home/zardosht/maria/mysql-build/mariadb-5.5.28a/sql/sql_select.cc:2396 In this stack, we are performing an index_next_same, and a condition has been pushed down. When we call handler_index_cond_check. we always get ICP_NO_MATCH and never get ICP_OUT_OF_RANGE, even though we go past the key that we should be retrieving. Is this by design? Is this a bug? Thanks -Zardosht

2 2

[Maria-developers] Spam in KB?
by Sergei Petrunia 07 Mar '13

07 Mar '13

Hi Daniel, I am looking at https://kb.askmonty.org/en/mariadb-5529-release-notes/ and I see at the top in the breadcrumbs: [Home] [ Why Shared Web Hosting Service Is Ideal For Small Businesses] [Development] and when I click on the shared hosting I get to: https://kb.askmonty.org/en/why-shared-web-hosting-service-is-ideal-for-smal… In my understanding this text has nothing to do with MariaDB? Is it link spam? BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] Rev 3633: MDEV-4241 fix
by Sergei Golubchik 06 Mar '13

06 Mar '13

Hi, Sanja! On Mar 06, sanja(a)askmonty.org wrote: > revno: 3633 > revision-id: sanja(a)askmonty.org-20130306191058-d293nik3l66vn4tp > parent: psergey(a)askmonty.org-20130301042335-x16j7uo1dwxxgqs9 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.3-MDEV-4241 > timestamp: Wed 2013-03-06 21:10:58 +0200 > message: > MDEV-4241 fix. > > Field_enum incorrectly inherited decimals() from Field_string. > Field_enum should be always integer in numeric context. Ok to push! Regards, Sergei

1 0

[Maria-developers] WL#253 New (by Igor): Take into account the selectivity of single-table range predicates on non-indexed columns
by worklog-noreply＠askmonty.org 06 Mar '13

06 Mar '13

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Take into account the selectivity of single-table range predicates on non-indexed columns CREATION DATE..: Wed, 06 Mar 2013, 17:25 SUPERVISOR.....: IMPLEMENTOR....: Igor COPIES TO......: Psergey CATEGORY.......: Server-BackLog TASK ID........: 253 (http://askmonty.org/worklog/?tid=253) VERSION........: Server-9.x STATUS.........: Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: DESCRIPTION: Description of the problem ========================== Currently the optimizer completely ignores any conditions on non-indexed columns when searching for the best execution plan. As a result in many cases it chooses a suboptimal plan. Let's consider the query: SELECT * FROM t1,t2 WHERE t1.a=t2.a and t2.b BETWEEN (1,3) assuming that: -table t1 contains 100 records -table t2 contains 1000 records -there is a primary index on t1(a) -there is a secondary index on t2(a) -there is no index defined on column t2.b -the selectivity of the condition t2.b BETWEEN (1,3) is high (~ 1%) Under these conditions currently the optimizer will choose the plan that accesses t1 using a table scan accesses t2 using index t2(a) checks the condition t2.b BETWEEN (1,3) This plan examines all rows of both tables and it performs 100 index look-ups. The alternative plan that: accesses table t2 in a table scan checks the condition t2.b BETWEEN (1,3) accesses t1 using index t1(a) also would examine all rows of t2, but it performs only ~10 look-ups to access ~10 rows of table t1. The second plan is expected to be more efficient and it is so. The plan to resolve the problem =============================== 1. Build single-table range conditions over different columns of all tables of the join query. 2. Calculate the selectivity of each such condition using persistent statistics on table columns. 3. Take this statistics into account when calculated the cardinality of each partial join that are evaluated by the optimizer. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0

[Maria-developers] deadlock, rotate and prepared xids
by MARK CALLAGHAN 05 Mar '13

05 Mar '13

Kristian, Did you do anything special to avoid deadlock with ::new_file_impl and prepared XIDs? My memory is vague but I thought you handled it. I added code to the FB patch group commit implementation to handle it. Both Yoshi and I hit deadlocks with that code in official MySQL 5.6: http://bugs.mysql.com/bug.php?id=68569 http://bugs.mysql.com/bug.php?id=68251 -- Mark Callaghan mdcallag(a)gmail.com

2 3