- developers - lists.mariadb.org

[Maria-developers] Moving process names, directories, TCP port etc from MySQL to MariaDB?
by Daniel Bartholomew 31 Aug '11

31 Aug '11

I just came across a question in the Knowledgebase that I missed because it was posted as an article, not a question. I've turned it into a proper question. http://kb.askmonty.org/en/moving-process-names-directories-tcp-port-etc-fro… ---------------------------------------------------------------------- Is there a time line for MariaDB to break away from using MySQL for things like its default port, directory names, suggested user name, lock directory, names of support programs, etc ? I know most things can be set in ./configure or in the .cnf file but isn't it time to make the move ? ---------------------------------------------------------------------- Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] Down/crossgrading MySQL 5.more to MariaDB 5.less
by Daniel Bartholomew 31 Aug '11

31 Aug '11

A new question has been posted to the Knowledgebase: http://kb.askmonty.org/en/downcrossgrading-mysql-5more-to-mariadb-5less ----------------------------------------------------------------------- Obsessed with dynamic columns, I'm considering moving our whole install from MySQL 5.5/MyISAM (just upgraded from 5.1 a few months back when this would have been a no-brainer) over/down to MariaDB/MyISAM 5.3. I am wondering if there is any official word on engine/table compatibility and what I would have to undo for this move. ----------------------------------------------------------------------- Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] MariaDB Aria based Heap Alternative
by md＠rpzdesign.com 30 Aug '11

30 Aug '11

Hello: I am beginning to work on a MEMORY/HEAP modification for the ARIA engine. This should compete favorably with the ORACLE times-ten option or SYBASE In-Memory DB. The goal is to replace the native MySQL Table-Locked HEAP table with a record-locked ARIA based HEAP table. It is my belief that not only should ARIA be the default transactional and non-transactional engine for Mysql, but it should be the default disk-based AND memory-based engine as well. Before I get too far down this road, is there an ARIA engine diagram that someone has done from the core ARIA team. Here is an example from Percona on XtraDB. http://www.mysqlperformanceblog.com/wp-content/uploads/2010/04/InnoDB_int.p… Also, do the core ARIA developers have comments on modification of the ARIA engine to include a ARIA HEAP setting so the ARIA engine operates only on in-memory tables. Have you ideas on things that are already available to achieve this functionality. I currently have a working ARIA based MEMORY/HEAP alternative running under MariaDB 2.8.x on Linux if anybody wants to know how to make that work immediately. Next week, when I get my server parts, I will run mysqlslap benchmark tests on an 8 core server that should push I/O past the point that my current Dual core testing computer running HEAP vs ARIA HEAP. I want to see if I can push the Native HEAP past the point of the table locking limit and see if I can SCALE the ARIA HEAP to performance way beyond Native HEAP. I will publish more info after I get responses from the Maria DB development community. Mark Diener (Note to self-Fixed table cache)

1 0

[Maria-developers] MWL#182: a problem select_type column, SIMPLE vs PRIMARY
by Sergey Petrunya 29 Aug '11

29 Aug '11

Hello, When coding MWL#182, I've found out that it is very difficult to print the same value of select_type as EXPLAIN does. Problem description ------------------- Moreover, any attempt to unify EXPLAIN and SHOW EXPLAIN code cause numerous test failures because of changed select_type. http://dev.mysql.com/doc/refman/5.5/en/explain-output.html#explain_select_t… defines: - SIMPLE Simple SELECT (not using UNION or subqueries) - PRIMARY Outermost SELECT In practice, this is is not always true. As a most striking example, grep for this query in subselect4.test: PREPARE stmt FROM "EXPLAIN SELECT EMPNAME FROM t1 WHERE EMPNUM IN (SELECT EMPNUM FROM t3 WHERE PNUM IN (SELECT PNUM FROM t2 WHERE PTYPE = 'Design'))"; The first execution will produce rows with select_type='PRIMARY', while the second will produce the same rows with select_type='SIMPLE'. Apparently, one of these is wrong. If you do a plain select from a VIEW that has a subquery create view V as select ... (subquery) ...; explain select * from V; you get EXPLAIN output which starts with a row that select_type='SIMPLE' and continues with rows describing the subquery, which causes a self-contradiction. Current solution ---------------- My approach to dealing with this is as follows: - MWL#182 code should not make changes to output of regular EXPLAIN SELECT queries. - Outputs of SHOW EXPLAIN and EXPLAIN SELECT of the same query may be slightly different This causes some ugliness in the code though, because I had to keep two ways to generate select_type values. I think this should be ok (if you disagree, please let me know) Future solution #1: get rid of SIMPLE ------------------------------------- I don't see a value of having select_type=SIMPLE (other than term "simple" being encouraging for novice users:) We could change SIMPLE to PRIMARY everywhere and get rid of the problem Future solution #2: use SIMPLE/PRIMARY approach of SHOW EXPLAIN --------------------------------------------------------------- EXPLAIN SELECT produces incorrect values because it calls st_select_lex::set_explain_type() before the query rewrites are done, so it can't see that - used VIEWs have subqueries - used subqueries will be flattened - etc. SHOW EXPLAIN operates on a query that is being executed, and that alone guarantees its output is closer to reality. This means, EXPLAIN SELECT output must be changed to match SHOW EXPLAIN output. This is a lot of changes across a number of .result files. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

3 2

[Maria-developers] Changes to table_statistics for mariadb 5.2
by Eric Bergen 26 Aug '11

26 Aug '11

Hi, I've been working on some improvements to the table and index statistics in mariadb that allow tracking on the session and query level. I've been pushing the changes to lp:~provenscaling-eric/maria/tivo The long form version of where I'm at in my hacking is at http://ebergen.net/wordpress/2011/07/28/second-update-of-modifying-table-st… I want to poll this list for ides on a few places I'm stuck and get the review process started to hopefully get some of these changes merged back into mainline mariadb. My first issue is around allocation of query ids for both show profiles and show table_statistics; Table statistics are enabled by userstat and profiles are controlled by profiling. Enabling these options at different times makes some confusing results: mysql> use test; Database changed mysql> set query_statistics_history_size=5; Query OK, 0 rows affected (0.00 sec) mysql> set profiling=1; Query OK, 0 rows affected (0.00 sec) mysql> select * from t limit 5; +-------+--------+ | t | u | +-------+--------+ | 14515 | 282874 | | 14521 | 258653 | | 14573 | 113276 | | 14577 | 826475 | | 14585 | 444645 | +-------+--------+ 5 rows in set (0.00 sec) mysql> show profiles; +----------+------------+-------------------------+ | Query_ID | Duration | Query | +----------+------------+-------------------------+ | 7 | 0.00052300 | select * from t limit 5 | +----------+------------+-------------------------+ 1 row in set (0.00 sec) mysql> set profiling=0; Query OK, 0 rows affected (0.00 sec) mysql> select * from t limit 10; +-------+--------+ | t | u | +-------+--------+ | 14515 | 282874 | | 14521 | 258653 | | 14573 | 113276 | | 14577 | 826475 | | 14585 | 444645 | | 14612 | 792545 | | 14626 | 483300 | | 14842 | 447267 | | 15325 | 38865 | | 15340 | 744424 | +-------+--------+ 10 rows in set (0.00 sec) mysql> show query table_statistics; +----------+--------------+------------+-----------+--------------+-------------------------+ | Query_id | Table_schema | Table_name | Rows_read | Rows_changed | Rows_changed_x_#indexes | +----------+--------------+------------+-----------+--------------+-------------------------+ | 2 | #temp# | #temp# | 15 | 15 | 15 | | 7 | test | t | 5 | 0 | 0 | | 10 | test | t | 10 | 0 | 0 | +----------+--------------+------------+-----------+--------------+-------------------------+ 3 rows in set (0.00 sec) mysql> show profiles; +----------+------------+-------------------------+ | Query_ID | Duration | Query | +----------+------------+-------------------------+ | 7 | 0.00052300 | select * from t limit 5 | +----------+------------+-------------------------+ 1 row in set (0.00 sec) My current thought is to create a show query history command that unifies both show profiles and user stats but only table stats or profiles will be available for any given query depending on the flags set when it ran. I can also create a separate show queries command only for table statistics. Any ideas on how to unify the two different profiling methods or split up the syntax? -- Eric Bergen eric.bergen(a)gmail.com http://www.ebergen.net

3 4

Re: [Maria-developers] [Commits] Rev 3156: MWL#182: Explain running statements
by Sergei Golubchik 24 Aug '11

24 Aug '11

Hi, Sergey! On Aug 23, Sergey Petrunya wrote: > MWL#182: Explain running statements > First code > - "Asynchronous procedure call" system I would like to review that part (at least), could you please tell me when it's ready for a review? > - new THD::check_killed() that serves APC request is called from > within most important loops > - put THD::check_killed() call into every loop where we could spend > significant amount of time This shouldn't be necessary, by trying to keep all long operations killable we've already put a "killed" check everywhere. If some long time consuming code needs a "killed" check but doesn't have it - it's a bug on itself (some code does not respond to KILL). Regards, Sergei

2 1

Re: [Maria-developers] [Commits] Rev 3165: Fix bug lp:825095 in file:///home/tsk/mprog/src/5.3/
by Sergey Petrunya 23 Aug '11

23 Aug '11

Hi Timour, ok to push. On Tue, Aug 23, 2011 at 12:00:29AM +0300, timour(a)askmonty.org wrote: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3165 > revision-id: timour(a)askmonty.org-20110822210013-egubev0wgyi00wjt > parent: igor(a)askmonty.org-20110820040205-1suikiokqfn8s81j > fixes bug(s): https://launchpad.net/bugs/825095 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Tue 2011-08-23 00:00:13 +0300 > message: > Fix bug lp:825095 > BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 3166: Fixed bug lp:825018 in file:///home/tsk/mprog/src/5.3/
by Sergey Petrunya 23 Aug '11

23 Aug '11

Hi Timour, Ok to push. On Tue, Aug 23, 2011 at 03:41:55PM +0300, timour(a)askmonty.org wrote: > At file:///home/tsk/mprog/src/5.3/ > > ------------------------------------------------------------ > revno: 3166 > revision-id: timour(a)askmonty.org-20110823123915-jxf9hvxq2hy03rr7 > parent: timour(a)askmonty.org-20110822210013-egubev0wgyi00wjt > fixes bug(s): https://launchpad.net/bugs/825018 > committer: timour(a)askmonty.org > branch nick: 5.3 > timestamp: Tue 2011-08-23 15:39:15 +0300 > message: > Fixed bug lp:825018 > > Analysis: > During the first execution of the query through the stored > procedure, the optimization phase calls > substitute_for_best_equal_field(), which calls > Item_in_optimizer::transform(). The latter replaces > Item_in_subselect::left_expr with args[0] via assignment. > In this test case args[0] is an Item_outer_ref which is > created/deallocated for each re-execution. As a result, > during the second execution Item_in_subselect::left_expr > pointed to freed memory, which resulted in a crash. > > Solution: > The solution is to use change_item_tree(), so that the > origianal left expression is restored after each execution. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB 5.2.8 Release Notes and Changelog
by Daniel Bartholomew 18 Aug '11

18 Aug '11

All, The files for MariaDB 5.2.8 were uploaded to the primary mirror last night and at this time we are waiting on only a handful of mirrors before we're ready to go live with this release. The release notes and changelog for this release are here: http://kb.askmonty.org/en/mariadb-528-release-notes http://kb.askmonty.org/en/mariadb-528-changelog If you have a minute, please review and suggest (or make) any necessary additions/modifications/etc... Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] WL#236 New (by Monty): Add MVCC to UPDATE in Aria, part 1
by worklog-noreply＠askmonty.org 16 Aug '11

16 Aug '11

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: Add MVCC to UPDATE in Aria, part 1 CREATION DATE..: Mon, 15 Aug 2011, 22:17 SUPERVISOR.....: Monty IMPLEMENTOR....: Monty COPIES TO......: CATEGORY.......: Maria-RawIdeaBin TASK ID........: 236 (http://askmonty.org/worklog/?tid=236) VERSION........: Server-5.5 STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 0 ESTIMATE.......: 50 (hours remain) ORIG. ESTIMATE.: 50 PROGRESS NOTES: DESCRIPTION: Add MVCC to UPDATE, part 1 Do a working proof-of-concept to better be able to estimate how long the full WL#235 task will take and to be able to estimate the initial performance of the first version of the work. ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v4.0.0)

1 0