- developers - lists.mariadb.org

[Maria-developers] MariaDB 5.3.1-beta
by Daniel Bartholomew 10 Sep '11

10 Sep '11

All, The packages for MariaDB 5.3.1-beta were uploaded to the primary mirror yesterday and all of the mirrors (except one) have the files now, so I've gone ahead and activated the download page and the release notes and changelog pages. * http://kb.askmonty.org/en/mariadb-531-release-notes * http://kb.askmonty.org/en/mariadb-531-changelog * http://downloads.askmonty.org/mariadb/5.3.1/ I will be waiting until Monday to send out the announcement email so if there is anything that should be added to the release notes, please let me know as soon as possible. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

Re: [Maria-developers] [Commits] Rev 3182: BUG#833600: Wrong result with view + outer join + uncorrelated subquery (non-semijoin) in file:///home/psergey/dev2/5.3-push14/
by Oleksandr Byelkin 09 Sep '11

09 Sep '11

Hi! 8 сент. 2011, в 22:24, Sergey Petrunya написал(а): > At file:///home/psergey/dev2/5.3-push14/ > > ------------------------------------------------------------ > revno: 3182 > revision-id: psergey(a)askmonty.org-20110908192447-h8rmi1gvivwh59eh > parent: psergey(a)askmonty.org-20110908173810-mcq7fj9d14ynyckq > committer: Sergey Petrunya <psergey(a)askmonty.org> > branch nick: 5.3-push14 > timestamp: Thu 2011-09-08 23:24:47 +0400 > message: > BUG#833600: Wrong result with view + outer join + uncorrelated subquery (non-semijoin) > - The bug was caused by outer join being incorrectly converted into inner because of > invalid return values of Item_direct_view_ref::not_null_tables(). > - Provided a correct Item_direct_view_ref::not_null_tables() function. The patch is OK [skip]

1 0

Re: [Maria-developers] [Question #169828]: MariaDB 5.3.0 7 crash in 4 minutes
by Kristian Nielsen 08 Sep '11

08 Sep '11

"Philip Stoev" <pstoev(a)askmonty.org> writes: > Bug https://bugs.launchpad.net/maria/+bug/824463, which is in state > "Fix Committed", is still present. I assume it is waiting for a > review. There may be others like it. I think we are using "Fix committed" and "Fix released" somewhat inconsistently. I see two different policies both being used: 1. "Fix committed" means the fix is pushed to a main tree. "Fix released" is set when an official release is made containing the fix. 2. "Fix committed" means a patch has been made but not pushed to main tree yet (eg. there is a commit mail or maybe pushed to a feature branch). "Fix released" means the fix is in a main tree. I prefer (2), since it simplifies the maintenance of bug states. When a fix is pushed to the main tree, the developer can mark the bug "fix released" with a comment noting in which release the bug will appear (just the next release number in the appropriate main tree, eg. "Fix will appear in 5.3.1"). With (1), we need an extra manual step where "someone" goes through bugs after release and figures out which should be set to "Fix released". I do not think this extra work gives any tangible benefits. So my suggestion is to adopt (2) as policy for MariaDB. However, the most important thing is that we adopt a consistent policy, whatever it is. - Kristian.

2 1

[Maria-developers] Will MariaDB eventually work with R1Soft CDP MySQL plugin?
by Daniel Bartholomew 07 Sep '11

07 Sep '11

A new question has been posted to the Knowledgebase: http://kb.askmonty.org/en/will-mariadb-eventually-work-with-r1soft-cdp-mysq… --------------------------------------------------------------------- According to R1Soft, their CDP MySQL plugin http://www.r1soft.com/linux-cdp/cdp-30-enterprise-edition/mysql/ for mysql backup isn't compatible with MariaDB http://www.webhostingtalk.com/showthread.php?t=1079176 . Would be nice if it did. Any chance of MariaDB folks working with R1Soft to make MariaDB 5.x compatible ? --------------------------------------------------------------------- Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] ALL/ANY/IN and NULL/TRUE/FALSE tests
by Oleksandr Byelkin 01 Sep '11

01 Sep '11

Hi! I checked the results according the link you gave me, also I thing the tests made compact enough.

1 0

[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