mariadb

Tree: ae476868a5

Author	SHA1	Message	Date
Igor Babaev	8540fa83bb	MDEV-19421 Basic 3-way join queries are not parsed. The parser returned a syntax error message for the queries with join expressions like this t1 JOIN t2 [LEFT \| RIGHT] JOIN t3 ON ... ON ... when the second operand of the outer JOIN operation with ON clause was another join expression with ON clause. In this expression the JOIN operator is right-associative, i.e. expression has to be parsed as the expression t1 JOIN (t2 [LEFT \| RIGHT] JOIN t3 ON ... ) ON ... Such join expressions are hard to parse because the outer JOIN is left-associative if there is no ON clause for the first outer JOIN operator. The patch implements the solution when the JOIN operator is always parsed as right-associative and builds first the right-associative tree. If it happens that there is no corresponding ON clause for this operator the tree is converted to left-associative. The idea of the solution was taken from the patch by Martin Hansson "WL#8083: Fixed the join_table rule" from MySQL-8.0 code line. As the grammar rules related to join expressions in MySQL-8.0 and MariaDB-5.5+ are quite different MariaDB solution could not borrow any code from the MySQL-8.0 solution.	6 years ago
Sergey Petrunya	e98bb64cbe	MDEV-4750: (patch#2): undo previous attempts to stabilize persistent table statistics with ANALYZE TABLE commands	13 years ago
Sergey Petrunya	bff40f3e0d	Fix test failure for join_outer_innodb.test: reuse the approach from vasil.dimov@oracle.com-20120521133620-glj6l0ntcsrz0wbl run ANALYZE TABLE.	13 years ago
Sergey Petrunya	c0ca15ab9c	MDEV-4270: crash in fix_semijoin_strategies_for_picked_join_order - Added testcase	13 years ago
Igor Babaev	21dad7ec30	Fixed bug mdev-4318. In some cases, when using views the optimizer incorrectly determined possible join orders for queries with nested outer and inner joins. This could lead to invalid execution plans for such queries.	13 years ago
Igor Babaev	e0a5319db3	Back-ported the fix and test cases for bugs #59487 and #43368 from the mysql-5.6 code line.	14 years ago
Igor Babaev	74fdbec68e	Fixed LP bug #848652 . The cause of this bug was the same as for bug 902356 fixed for 5.3.	14 years ago
Jorgen Loland	47b774b21c	BUG#58456 - Assertion 0 in QUICK_INDEX_MERGE_SELECT::need_sorted_output in opt_range.h In this bug, there are two alternative access plans: * Index merge range access * Const ref access best_access_path() decided that the ref access was preferrable, but make_join_select() still decided to point SQL_SELECT::quick to the index merge because the table had type==JT_CONST which was not handled. At the same time the table's ref.key still referred to the index the ref access would use indicating that ref access should be used. In this state, different parts of the optimizer code have different perceptions of which access path is in use (ref or range). test_if_skip_sort_order() was called to check if the ref access needed ordering, but test_if_skip_sort_order() got confused and requested the index merge to return records in sorted order. Index merge cannot do this, and fired an ASSERT. The fix is to take join_tab->type==JT_CONST into concideration when make_join_select() decides whether or not to use the range access method. mysql-test/r/join_outer_innodb.result: Add test for BUG#58456 mysql-test/t/join_outer_innodb.test: Add test for BUG#58456	15 years ago
Jorgen Loland	664f06de7c	BUG#58456 - Assertion 0 in QUICK_INDEX_MERGE_SELECT::need_sorted_output in opt_range.h In this bug, there are two alternative access plans: * Index merge range access * Const ref access best_access_path() decided that the ref access was preferrable, but make_join_select() still decided to point SQL_SELECT::quick to the index merge because the table had type==JT_CONST which was not handled. At the same time the table's ref.key still referred to the index the ref access would use indicating that ref access should be used. In this state, different parts of the optimizer code have different perceptions of which access path is in use (ref or range). test_if_skip_sort_order() was called to check if the ref access needed ordering, but test_if_skip_sort_order() got confused and requested the index merge to return records in sorted order. Index merge cannot do this, and fired an ASSERT. The fix is to take join_tab->type==JT_CONST into concideration when make_join_select() decides whether or not to use the range access method.	15 years ago
unknown	0dbe99f8aa	Move innodb dependent test to join_outer_innodb mysql-test/r/join_outer_innodb.result: New BitKeeper file ``mysql-test/r/join_outer_innodb.result'' mysql-test/t/join_outer_innodb.test: New BitKeeper file ``mysql-test/t/join_outer_innodb.test''	20 years ago
msvensson@neptunus.(none)	5367facc66	Move innodb dependent test to join_outer_innodb	20 years ago

10 Commits (ae476868a5394041a00e75a29c7d45917e8dfae8)