Commit graph

1259 commits

Author SHA1 Message Date
Sergei Golubchik
0b9a0a3517 5.5 merge 2014-02-25 16:04:35 +01:00
Sergei Golubchik
ff2e82f4a1 5.3 merge 2014-02-22 22:51:20 +01:00
Igor Babaev
3e03c9eae9 After constant row substitution the optimizer should call the method
update_used_tables for the the where condition to update cached
indicators of constant subexpressions. It should be done before further
possible simplification of the where condition.

This change caused simplification of the executed where conditions 
in many test cases.
2014-02-20 21:27:33 -08:00
Michael Widenius
10001c8e4f Automatic merge 2014-02-05 19:23:11 +02:00
Sergei Golubchik
72c20282db 10.0-base merge 2014-02-03 15:22:39 +01:00
Sergei Golubchik
59d9d08e2b 5.5 merge 2014-02-01 00:54:03 +01:00
Michael Widenius
43f6e118fe Fixes for CREATE_OR_REPLACE
- MDEV-5587 Server crashes in Locked_tables_list::restore_lock on CREATE OR REPLACE .. SELECT under LOCK
- MDEV-5586 Assertion `share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL' fails in tdc_remove_table
- MDEV-5588 Strange error on CREATE OR REPLACE table over an existing view

mysql-test/r/create_or_replace.result:
  Added test cases
mysql-test/r/lowercase_view.result:
  New error message
mysql-test/r/merge.result:
  New error message
mysql-test/r/multi_update.result:
  New error message
mysql-test/r/subselect.result:
  New error message
mysql-test/r/subselect_exists_to_in.result:
  New error message
mysql-test/r/subselect_no_mat.result:
  New error message
mysql-test/r/subselect_no_opts.result:
  New error message
mysql-test/r/subselect_no_scache.result:
  New error message
mysql-test/r/subselect_no_semijoin.result:
  New error message
mysql-test/r/view.result:
  New error message
mysql-test/suite/funcs_1/r/myisam_views-big.result:
  New error message
mysql-test/t/create_or_replace.test:
  New tests
mysql-test/t/view.test:
  New error message
sql/share/errmsg-utf8.txt:
  Added new error message
sql/sql_base.cc:
  Updated error message
  Do an automatic UNLOCK TABLES if we don't have any locked tables (safety fix)
sql/sql_db.cc:
  Updated arguments
sql/sql_load.cc:
  New error message
sql/sql_parse.cc:
  Check that we are not using a table we are dropping and re-creating
sql/sql_table.cc:
  Added parameter to mysql_rm_table_no_locks() to not automaticly do UNLOCK TABLES
  Added better error message if trying to drop a view with DROP TABLE
  Don't try to create something we select from
sql/sql_table.h:
  Updated prototypes
2014-01-31 12:06:28 +02:00
unknown
b0aaf5c6f5 Merge 5.3->5.5 2014-01-15 16:07:50 +02:00
unknown
3aa370bb69 MDEV-5515: 2nd execution of a prepared statement returns wrong results
update_used_tables() should be called after handling derived tables in any case.
2014-01-13 21:30:42 +02:00
unknown
57400ee681 MDEV-5414: RAND() in a subselect : different behavior in MariaDB and MySQL
Materialization forced in case if rand() used in view or derived table to avoud several calls of rand for gting value of a field.

Fixed set variable uncachable flag from - it shouldbe a side effect not a random value.
2013-12-18 15:59:51 +02:00
unknown
55de9b0468 merge 10-base->10.0 2013-11-11 23:40:53 +02:00
unknown
3a75900b91 merge 5.5->10.0-base 2013-11-11 22:47:04 +02:00
unknown
dfed447888 merge 5.3->5.5 2013-11-11 20:38:04 +02:00
unknown
c98a054fde MDEV-5153: Server crashes in Item_ref::fix_fields on 2nd execution of PS with LEFT JOIN and MERGE view or SELECT SQ
1. Transformation of row IN subquery made the same as single value.
2. replace_where_subcondition() made working on several layers of OR/AND because it called on expression before fix_fields().
2013-11-11 17:28:14 +02:00
Sergei Golubchik
a30e87414c merge 10.0-base into 10.0 2013-11-04 08:43:56 +01:00
Sergei Golubchik
5c9d2c6c9f MDEV-4332 Increase username length from 16 characters
10.0 part of the task, fix system tables
2013-11-03 16:31:52 +01:00
Alexander Barkov
1039182354 Merge 5.5 -> 10.0-base 2013-10-16 20:26:16 +04:00
Alexander Barkov
5064d03b80 Merge 5.3 -> 5.5. 2013-10-16 17:58:54 +04:00
Sergey Petrunya
1e36cbfa39 MDEV-3798: [SHOW] EXPLAIN UPDATE/DELETE
- Merge with 10.0-base
2013-10-15 11:51:41 +04:00
unknown
3cc3bcfcc5 MDEV-5107:Left Join Yields All Nulls Instead of Appropriate Matches
MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery

Make reset null_row same as it was set in evaluate_null_complemented_join_record().

The problem was that view firlds detect null_row by not-yet-reset table.
2013-10-11 15:57:19 +03:00
unknown
8f4eb208d2 merge 10.0-base -> 10.0 2013-10-17 19:01:57 +03:00
Sergey Petrunya
e5d13c1567 Merge 10.0-base -> 10.0 2013-10-16 13:38:42 +04:00
Sergei Golubchik
9af177042e 10.0-base merge.
Partitioning/InnoDB changes are *not* merged (they'll come from 5.6)
TokuDB does not compile (not updated to 10.0 SE API)
2013-09-21 10:14:42 +02:00
Sergey Petrunya
662bfed027 [SHOW] EXPLAIN UPDATE/DELETE, code re-structuring
- Merge with current 10.0-base
2013-08-24 00:46:49 +04:00
Igor Babaev
4eddb2c221 Merge 5.3->5.5.
In particular:
Merged the patch for bug mdev-4418 from 5.3 into 5.5.
Fixed a bug in the patch that should be backported to 5.3.
2013-08-18 19:58:51 -07:00
Igor Babaev
25c152018d Fixed bug mdev-4418.
After single row substitutions there might appear new equalities.
They should be properly propagated to all AND/OR levels the WHERE
condition. It's done now with an additional call of remove_eq_conds().
2013-08-16 22:01:47 -07:00
Sergei Golubchik
b7b5f6f1ab 10.0-monty merge
includes:
* remove some remnants of "Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING"
* introduce LOCK_share, now LOCK_ha_data is strictly for engines
* rea_create_table() always creates .par file (even in "frm-only" mode)
* fix a 5.6 bug, temp file leak on dummy ALTER TABLE
2013-07-21 16:39:19 +02:00
Sergei Golubchik
5f6380adde 10.0-base merge 2013-07-18 16:46:57 +02:00
unknown
aa6d8e4950 fixed result (error message and error message intercepting). 2013-07-05 17:06:02 +03:00
Sergey Petrunya
8b7bbcf4dc [SHOW] EXPLAIN UPDATE/DELETE, code re-structuring
- Make query plan be re-saved after the first join execution
  (saving it after JOIN::cleanup is too late because EXPLAIN output 
   is currently produced before that)
- Handle QPF allocation/deallocation for edge cases, like unsuccessful
  BINLOG command.
- Work around the problem with UNION's direct subselects not being visible.
- Update test results ("Using temporary; Using filesort" are now always printed 
  last in the Extra column)
- This cset gets rid of memory leaks/crashes. Some result mismatches still remain.
2013-06-27 16:41:12 +04:00
Sergey Petrunya
99a8bfe68c [SHOW] EXPLAIN UPDATE/DELETE, code re-structuring
- Update view.result (old EXPLAIN didn't match the execution)
- Put in a stub code to work around the 
  SELECT ... UNION SELECT ... ORDER BY (subuqery) problem
2013-06-27 01:00:22 +04:00
Sergey Petrunya
1c6fc3f6b9 [SHOW] EXPLAIN UPDATE/DELETE, code re-structuring
Part 2 of:
- Pass more tests
- select with subselects is now shown with type=PRIMARY where it used to be (incorrectly) 'SIMPLE'
2013-06-18 19:21:00 +04:00
unknown
b54a4b7621 5.3 -> 5.5 Merge 2013-06-17 20:33:36 +03:00
unknown
ad947563ac MDEV-4593: p_s: crash in simplify_joins with delete using subselect from view
mysql_derived_merge_for_insert() should not be called for views or derived tables which are not put (directly or via other views) in main SELECT_LEX "join list".
2013-06-06 23:33:40 +03:00
Sergei Golubchik
a9035be5b7 10.0-base merge 2013-04-15 15:09:22 +02:00
Sergei Golubchik
213f1c76a0 5.3->5.5 merge 2013-02-28 22:47:29 +01:00
Igor Babaev
ed7671d523 Fixed bug mdev-4172.
This bug in the legacy code could manifest itself in queries with
semi-join materialized subqueries.
When a subquery is materialized all conditions that are imposed
only on the columns belonging to the tables from the subquery 
are taken into account.The code responsible for subquery optimizations
that employes subquery materialization  makes sure to remove these
conditions from the WHERE conditions of the query obtained after
it has transformed the original query into a query with a semi-join.
If the condition to be removed is an equality condition it could
be added to ON expressions and/or conditions from disjunctive branches
(parts of OR conditions) in an attempt to generate better access keys
to the tables of the query. Such equalities are supposed to be removed
later from all the formulas where they have been added to.
However, erroneously, this was not done in some cases when an ON
expression and/or a disjunctive part of the OR condition could
be converted into one multiple equality. As a result some equality
predicates over columns belonging to the tables of the materialized
subquery remained in the ON condition and/or the a disjunctive 
part of the OR condition, and the excuter later, when trying to
evaluate them, returned wrong answers as the values of the fields
from these equalities were not valid.  
This happened because any standalone multiple equality (a multiple
equality that are not ANDed with any other predicates) lacked
the information about equality predicates inherited from upper
levels (in particular, inherited from the WHERE condition).
The fix adds a reference to such information to any standalone
multiple equality.
2013-02-21 17:13:12 -08:00
Igor Babaev
c9b63e6a49 Fixed bug mdev-3913.
The wrong result set returned by the left join query  from
the bug test case happened due to several inconsistencies 
and bugs of the legacy mysql code.

The bug test case uses an execution plan that employs a scan
of a materialized IN subquery from the WHERE condition.
When materializing such an IN- subquery the optimizer injects
additional equalities  into the WHERE clause. These equalities
express the constraints imposed by the subquery predicate.
The injected equality of the query in the  test case happens
to belong to the same equality class, and a new equality 
imposing a condition on the rows of the materialized subquery
is inferred from this class. Simultaneously the multiple
equality is added to the ON expression of the LEFT JOIN
used in the main query.
  
The inferred equality of the form f1=f2 is taken into account
when optimizing the scan of  the rows the temporary table 
that is the result of the subquery materialization: only the 
values of the field f1 are read from the table into the record 
buffer. Meanwhile the inferred equality is removed from the
WHERE conditions altogether as a constraint on the fields
of the temporary table that has been used when filling this table. 
This equality is supposed to be removed from the ON expression
when the multiple equalities of the ON expression are converted
into an optimal set of equality predicates. It supposed to be
removed from the ON expression as an equality inferred from only
equalities of the WHERE condition. Yet, it did not happened
due to the following bug in the code.

Erroneously the code tried to build multiple equality for ON
expression twice: the first time, when it called optimize_cond()
for the WHERE condition, the second time, when it called
this function for the HAVING condition. When executing
optimize_con() for the WHERE condition  a reference
to the multiple equality of the WHERE condition is set
in the multiple equality of the  ON expression. This reference
would allow later to convert multiple equalities of the
ON expression into equality predicates. However the 
the second call of build_equal_items() for the ON expression
that happened when optimize_cond() was called for the
HAVING condition reset this reference to NULL.

This bug fix blocks calling build_equal_items() for ON
expressions for the second time. In general, it will be
beneficial for many queries as it removes from ON 
expressions any equalities that are to be checked for the
WHERE condition.
The patch also fixes two bugs in the list manipulation
operations and a bug in the function  
substitute_for_best_equal_field() that resulted
in passing wrong reference to the multiple equalities
of where conditions when processing multiple
equalities  of ON expressions.

The code of substitute_for_best_equal_field() and
the code the helper function eliminate_item_equal()
were also streamlined and cleaned up.
Now the conversion of the multiple equalities into
an optimal set of equality predicates first produces
the sequence of the all equalities processing multiple
equalities one by one, and, only after this, it inserts
the equalities at the beginning of the other conditions.

The multiple changes in the output of EXPLAIN
EXTENDED are mainly the result of this streamlining,
but in some cases is the result of the removal of
unneeded equalities from ON expressions. In
some test cases this removal were reflected in the
output of EXPLAIN resulted in disappearance of 
“Using where” in some rows of the execution plans.
2013-02-20 18:01:36 -08:00
Sergei Golubchik
ab83952f29 10.0-base merge 2013-01-31 09:48:19 +01:00
Sergei Golubchik
aca8e7ed6b 5.3 merge 2013-01-15 19:07:46 +01:00
unknown
6f26aac940 MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery
from a MERGE view.

The problem was in the lost ability to be null for the table of a left join if it
is a view/derived table.

It hapenned because setup_table_map(), was called earlier then we merged
the view or derived.

Fixed by propagating new maybe_null flag during Item::update_used_tables().

Change in join_outer.test and join_outer_jcl6.test appeared because
IS NULL reported no used tables (i.e. constant) for argument which could not be
NULL and new maybe_null flag was propagated for IS NULL argument (Item_field)
because table the Item_field belonged to changed its maybe_null status.
2012-12-28 14:41:46 +02:00
unknown
701419b02f Merge MariaDB 10.0-base to MariaDB 10.0 2012-12-18 15:01:58 +01:00
unknown
0aad592f49 MDEV-3914 fix.
Fixed algorithm of detecting of first real table in view/subquery-in-the-FROM-clase.
2012-12-05 21:06:00 +02:00
unknown
b8b875cb79 Fix of MDEV-3874: Server crashes in Item_field::print on a SELECT from a MERGE view with materialization+semijoin, subquery, ORDER BY.
The problem was that in debugging binaries it try to print item to assign human readable name to the item.
But subquery item was already freed (join_free/cleanup with full cleanup) so Item_field refers to temporary
table which memory had been already freed.
2012-11-26 21:22:44 +02:00
unknown
6d179d7c73 MDEV-3862 Lift limitation for merging VIEWS with Subqueries in SELECT list. 2012-11-20 15:11:22 +02:00
Sergei Golubchik
68baf07dcd 5.3 merge 2012-10-18 23:33:06 +02:00
unknown
362c2bca3e Fix of MDEV-3799.
Find left table in right join (which turned to left join by reordering tables in join list but phisical order of tables of SELECT left as it was).
2012-10-10 22:42:50 +03:00
unknown
b0d11675fb Fix of MDEV-589.
The problem was in incorrect detection of merged views in tem_direct_view_ref::used_tables() .
2012-10-05 12:26:55 +03:00
Igor Babaev
c56fd181bf Added the reported test case for LP bug #823237 (a duplicate of bug #823189). 2012-10-01 19:04:17 -07:00
Michael Widenius
3a793b9d4d Added new status variables:
feature_dynamic_columns,feature_fulltext,feature_gis,feature_locale,feature_subquery,feature_timezone,feature_trigger,feature_xml
Opened_views, Executed_triggers, Executed_events
Added new process status 'updating status' as part of 'freeing items'

mysql-test/r/features.result:
  Test of feature_xxx status variables
mysql-test/r/mysqld--help.result:
  Removed duplicated 'language' variable.
mysql-test/r/view.result:
  Test of opened_views
mysql-test/suite/rpl/t/rpl_start_stop_slave.test:
  Write more information on failure
mysql-test/t/features.test:
  Test of feature_xxx status variables
mysql-test/t/view.test:
  Test of opened_views
sql/event_scheduler.cc:
  Increment executed_events status variable
sql/field.cc:
  Increment status variable
sql/item_func.cc:
  Increment status variable
sql/item_strfunc.cc:
  Increment status variable
sql/item_subselect.cc:
  Increment status variable
sql/item_xmlfunc.cc:
  Increment status variable
sql/mysqld.cc:
  Add new status variables to 'show status'
sql/mysqld.h:
  Added executed_events
sql/sql_base.cc:
  Increment status variable
sql/sql_class.h:
  Add new status variables
sql/sql_parse.cc:
  Added new process status 'updating status' as part of 'freeing items'
sql/sql_trigger.cc:
  Increment status variable
sql/sys_vars.cc:
  Increment status variable
sql/tztime.cc:
  Increment status variable
2012-09-09 01:22:06 +03:00