- developers - lists.mariadb.org

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, Jocelyn! On May 31, Jocelyn Fournier wrote: > > Just to be sure : it means also the debian package will be properly > linked against libaio ? (it wasn't the case in 5.5.23 release). Unfortunately not. I mean that debian packages will be linked against libaio only in 5.5.25, but not in 5.5.24. Currently (in 5.5.24) only RPM packages are linked against libaio. Debian packages and bintar package are not. Regards, Sergei

1 0

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, md! On May 31, md wrote: > Sergei: > > I guess you can get 5.5.24 to build ok. I had a bunch of trouble with > 5.5.23 and a compiler error that I could not seem to make go away. > > [ 47%] Building CXX object > storage/oqgraph/CMakeFiles/oqgraph.dir/graphcore.cc.o > > In file included from > /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27:0, This is a known issue. An the OQGraph engine that we include is incompatible with the new Boost. It is a third-party engine, not ours. OQGraph developer knows about this problem and he's working on it. When he'll fix OQGraph, we will update it in our sources. Meanwhile we build without. Try to run cmake -DWITHOUT_OQGRAPH=1 in your build tree, and run make again. In 5.5.25 I'll make this the default behavior, until OQGraph is fixed. Regards, Sergei

1 0

Re: [Maria-developers] MariaDB 5.5.24 release prep
by Sergei Golubchik 31 May '12

31 May '12

Hi, Jocelyn! On May 31, Jocelyn Fournier wrote: > > Just wondering if the build issue with binaries and packages which don't > use native AIO is fixed as well ? > > (See https://bugs.launchpad.net/maria/+bug/988204 ) Doesn't seem so :( For some reason it was submitted in the wrong bugtracker, and I missed it when preparing a release. Sorry for this, it'll be in 5.5.25. This time - for sure. Note that 5.5 RPM packages are not affected by this bug - they are all properly linked with AIO. Regards, Sergei

1 0

[Maria-developers] MariaDB 5.5.24 release prep
by Daniel Bartholomew 31 May '12

31 May '12

All, I'm uploading the files for MariaDB 5.5.24 and getting other bits and pieces ready. Preliminary versions of the Release Notes and Changelog are available here: http://kb.askmonty.org/en/mariadb-5524-release-notes/ http://kb.askmonty.org/en/mariadb-5524-changelog/ The big news in this release is the new RPM packages and the YUM repositories. I'm still working on getting all the various bits set up, but it's all coming together and with any luck, I should be able to flip the switch and announce the release tomorrow morning (U.S. Eastern Time). In the mean time, if there is anything which should be mentioned in the Release Notes, please let me know ASAP or jump in and edit the Release Notes directly. Thanks! -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] Support of the extended syntax for ANALYZE
by Sergei Golubchik 26 May '12

26 May '12

Hi, Igor! On May 10, Igor Babaev wrote: > Serg, > > Here's the patch we talked about on IRC today. ... > +ANALYZE TABLE t1(COLUMN(), INDEX()); > +ANALYZE TABLE t1(COLUMN(c,e,b), INDEX(idx2,idx4)); > +ANALYZE TABLE t1(COLUMN(*), INDEX(*)); I see what you want to do. I think it'll be more SQL-like, if it'll be more verbose, for example ANALYZE TABLE t1 FOR COLUMNS (c,e,d) INDEXES (idx2, idx4); I would prefer to drop parentheses too, but then the grammar will become ambiguous :( And instead of double (*) it could simply be ANALYZE TABLE t1 FULL; or ALL; it'd be similar to CHECK TABLE t1 EXTENDED; REPAIR TABLE t1 QUICK; etc Alternatively, it could have an explicit "PERSISTENT" keyword: ANALYZE TABLE t1 PERSISTENT; -- meaning all columns and indexes ANALYZE TABLE t1 PERSISTENT FOR COLUMNS (c,e,d) INDEXES (idx2, idx4); That's probably the best one. Reasonably SQL-like. And the most common use case (analyze all) is short, it's clearly the main, default behavior. And the clause to specify columns and indexes extends the default syntax. Regards, Sergei

4 6

[Maria-developers] SHOW EXPLAIN and LOCK_thd_data
by Sergei Petrunia 26 May '12

26 May '12

Hi Sergei, I've got a problem with SHOW EXPLAIN and LOCK_thd_data. SHOW EXPLAIN was modeled after the KILL command: it's actions are: lock LOCK_thread_count; find the thread $target_thr we need explain for; lock $target_thr->LOCK_thread_count; unlock LOCK_thread_count; send SHOW EXPLAIN request to $target_thr. wait until request is executed (or discarded) unlock $target_thr->LOCK_thread_count; This scheme works, as long as the target thread doesn't select from information_schema tables. With queries over I_S tables, it breaks, because I_S table may try to acquire current_thd->LOCK_thread_count during execution. Below I provide a stacktrace of one such case, line numbers are from lp:~maria-captains/maria/5.5-show-explain. My first thought was to change LOCK_thread_count to be a read/write mutex, but I wanted to hear your opinion, too. (gdb) wher #0 inline_mysql_mutex_lock (that=0xa1111d4, src_file=0x894b75c "sql/sql_class.h", src_line=3020) at include/mysql/psi/mysql_thread.h:608 #1 0x081dda85 in THD::set_open_tables (this=0xa1104b0, open_tables_arg=0xa12de10) at sql/sql_class.h:3020 #2 0x081d9024 in open_table (thd=0xa1104b0, table_list=0xa1289b0, mem_root=0x99134000, ot_ctx=0x99134020) at sql/sql_base.cc:3180 #3 0x081d9aee in open_and_process_table (thd=0xa1104b0, lex=0x9913417c, tables=0xa1289b0, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0, has_prelocking_list=false, ot_ctx=0x99134020, new_frm_mem=0x99134000) at sql/sql_base.cc:4509 #4 0x081da269 in open_tables (thd=0xa1104b0, start=0x991340d4, counter=0x991340bc, flags=1026, prelocking_strategy=0x991340c0) at sql/sql_base.cc:4958 #5 0x081da6de in open_normal_and_derived_tables (thd=0xa1104b0, tables=0xa1289b0, flags=1026, dt_phases=34) at sql/sql_base.cc:5617 #6 0x082a3e23 in fill_schema_table_by_open (thd=0xa1104b0, is_show_fields_or_keys=true, table=0xa1263c0, schema_table=0x8c262b0, orig_db_name=0x99134e04, orig_table_name=0x99134e1c, open_tables_state_backup=0x99134d94, can_deadlock=false) at sql/sql_show.cc:3659 #7 0x082b8638 in get_all_tables (thd=0xa1104b0, tables=0xa11d560, cond=0x0) at sql/sql_show.cc:4214 #8 0x0829f943 in do_fill_table (thd=0xa1104b0, table_list=0xa11d560, join_table=0xa128548) at sql/sql_show.cc:7503 #9 0x0829fce2 in get_schema_tables_result (join=0xa1279a8, executed_place=PROCESSED_BY_JOIN_EXEC) at sql/sql_show.cc:7610 #10 0x0829468d in JOIN::exec_inner (this=0xa1279a8) at sql/sql_select.cc:2354 #11 0x082931c8 in JOIN::exec (this=0xa1279a8) at sql/sql_select.cc:2201 BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

Re: [Maria-developers] Please review: [Commits] Rev 3405: Test case for bug lp:1001117, MySQL BUG#12330344 in file:///home/tsk/mprog/src/5.5-lpb944706/
by Sergei Petrunia 24 May '12

24 May '12

Hi Timour, On Thu, May 24, 2012 at 02:12:12PM +0300, Timour Katchaounov wrote: > Sergey, > > Could you please review the following patch. So far it is only in my > tree for bug lp:944706 (because this tree already fixes the problem as > explained below). > Ok to push. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MDEV-83: pushdown of expensive predicates
by Sergei Petrunia 21 May '12

21 May '12

Hi Timour, Some thoughts about MDEV-83. The jira entry says: > The main difference in these two plans is that with the first execution plan > the dependent subquery: ... is evaluated before the table part is accessed > while many rows where (p_name like 'forest%') is not true are filtered out > and evaluation of the dependent subquery is not needed for them. The way I read this, the only way one could figure out that the subquery should be evaluated at later phase (after table part) is to figure out that selectivity of table `part`, together with its condition of p_name like 'forest%' is less than one. That way, subquery is evaluated fewer times, and query execution will be cheaper. I don't see any index that covers p_name column. This means that current optimizer has no clue about selectivity of conditions over p_name column, and hence is unable to make the correct decision. If I add an index on p_name, then I get a different query plan (I didn't check if is slower or faster than the original). I think, one of the first things this MDEV needs is to figure out how exactly we will get selectivities for non-indexed columns. If we get them, and start to take them into account in join optimizer(*), the example provided in this MDEV/ bug may just go away :-). The general problem will remain, though. (*) { Currently, the optimizer has "quick_condition_rows", which may cause join fanout to be less than 1 (check out examples with EXPLAIN EXTENDED and filtered != 100% in the testsuite). The problem is that quick_condition_rows is not used consistently for all ways to access the table, for example it is not taken into account when considering ref access. I do not know whether Igor's work in best_access_path() includes making it consistently make use of quick_condition_rows estimates. } == Subquery predicate attachment considerations == Some thoughts about the problem. There are three factors we may want/need to take into account when attaching subquery predicate to some join_tab: 1. Fanout of join tabs 2. Cost of the subquery predicate evaluation 3. Selectivity of the subquery predicate. The example used in this MDEV item can be resolved by taking into account #1 and #2. For the first step, we only need to know - accurate join tab fanout (#1), - that subquery predicate evaluation has some cost ( #2 != 0) these two allow us to set/resolve a task of attaching the subquery predicate to the join_tab where total cost of its evaluations is minimized. The exact value of subquery evaluation cost is irrelevant. It will only become relevant when/if we start to make a choice between evaluating subquery predicate, or preforming join with the next join_tab. In order for that choice to be meaningful, we will need to have an idea about subquery predicate's selectivity. That way, we will be able to make a choice between 1. evaluate subquery, then make join with next join tab cost(subquery_pred) + selectivity(subquery_pred) * cost(join_tab) and 2. make join with next join_tab, then evaluate the subquery: cost(join_tab) + selectivity(join_tab) * cost(join_tab) BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] MDEV-136 Non-blocking "set read_only"
by Sergei Golubchik 20 May '12

20 May '12

Hi, Holyfoot! Looks good to me! See a couple of comments below. Please push after fixing all that. On May 17, holyfoot(a)askmonty.org wrote: > ------------------------------------------------------------ > revno: 3518 > revision-id: holyfoot(a)askmonty.org-20120517131405-y12erfkgta2ym2pn > parent: sanja(a)montyprogram.com-20120507181437-1zl1v1uxje7v6994 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-136 > timestamp: Thu 2012-05-17 18:14:05 +0500 > message: > MDEV-136 Non-blocking "set read_only". > Handle the 'set read_only=1' in lighter way, than the FLUSH TABLES READ LOCK; > For the transactional engines we don't wait for operations on that tables to finish. > > === modified file 'mysql-test/t/read_only_innodb.test' > --- a/mysql-test/t/read_only_innodb.test 2008-04-08 05:20:58 +0000 > +++ b/mysql-test/t/read_only_innodb.test 2012-05-17 13:14:05 +0000 > @@ -75,7 +75,28 @@ > SELECT * FROM t1; > COMMIT; > > -connection default; > +# > +# Tests that LOCK TABLE doesn't block the SET READ_ONLY=1 for the InnoDB tables > +# > +connection default; > +UNLOCK TABLES; > + > +--echo connection con1; > +connection con1; > +lock table t1 write; See whether you can directly test that the table was not reopened. Perhaps by examining the corresponding SHOW STATUS variables you could do that. > + > +--echo connection default; > +connection default; > +set global read_only=1; > + > +--echo connection con1; > +connection con1; > +unlock tables; > + > +--echo connection default; > +connection default; > +SET GLOBAL read_only=0; > + > UNLOCK TABLES; > DROP TABLE t1; > DROP USER test@localhost; > === modified file 'sql/sql_base.cc' > --- a/sql/sql_base.cc 2012-04-19 06:16:30 +0000 > +++ b/sql/sql_base.cc 2012-05-17 13:14:05 +0000 > @@ -933,7 +938,14 @@ > for (uint idx=0 ; idx < open_cache.records ; idx++) > { > TABLE *table=(TABLE*) hash_element(&open_cache,idx); > - if (table->in_use) > + /* We don't increment the refresh_version when set_readonly_mode, */ > + /* but we still need non-transactional tables to be reopened. */ > + /* So we set their versions as 'refresh_version - 1', which marks */ > + /* them for the 'needs_reopen_or_table_lock()' */ please, use the standard mysql comment style as you can see everywhere in the sources > + if (set_readonly_mode && !table->file->has_transactions()) > + table->s->version= refresh_version-1; better set it to 0, that's what tdc_remove_table() does. And we won't need to think about possible race conditions. > + if (table->in_use && > + (!set_readonly_mode || !table->file->has_transactions())) > table->in_use->some_tables_deleted= 1; > } > } Regards, Sergei

1 0

[Maria-developers] On the DBUG_ASSERT in create_ref_for_key()
by Sergei Petrunia 20 May '12

20 May '12

Hi Sergei, Re the DBUG_ASSERT(length > 0 && keyparts != 0); line in create_ref_for_key() in 5.3: I've looked - the assert can be commented out, because it's valid to have length=0 && !keyparts for a variant of LooseScan algorithm. Some more details: I've tried to come up another assert statement, that would allow length==0 only when LooseScan is used. Unfortunately, it is not easy - the query plan is encoded in join->best_positions, while create_ref_for_key() has access only to the JOIN_TAB. Since SJ-Materialization, the query plan is represented with multiple JOIN_TAB arrays, while there is only one POSITION array, which means that one needs to loop to find the POSITION which corresponds to the JOIN_TAB. EXPLAIN and execution use JOIN_TAB::loosescan_match_tab, but it is set by setup_semijoin_dups_elimination() which is invoked after create_ref_for_key() is. BR Sergei -- Sergei Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0