- 30 Nov, 2011 1 commit
-
-
unknown authored
-
- 29 Nov, 2011 3 commits
-
-
unknown authored
-
unknown authored
The cause of the wrong result was that Item_ref_null_helper::get_date() didn't use a method of the *_result() family, and fetched the data for the field from the current row instead of result_field. Changed to use the correct *_result() method, like to all other similar methods of Item_ref_null_helper.
-
Alexey Botchkov authored
DISJOINT can't be properly optimized with the RTree keys in MyISAM also. per-file comments: storage/myisam/rt_index.c bug 857066 Wrong result with ST_DISJOINT when using an index. don't optimize DISJOINT with the RTree keys.
-
- 28 Nov, 2011 3 commits
-
-
Alexey Botchkov authored
the ST_DISJOINT can't be properly optimized with the RTree key at the moment. per-file comments: storage/maria/ma_rt_index.c bug 857066 Wrong result with ST_DISJOINT when using an index disabled optimization for the DISJOINT case.
-
unknown authored
Analysis: lp:894397 was a consequence of a prior incorrect fix of lp:833777 which didn't take into account that even when all tables are constant there may be correlated conditions, and the where clause is not equivalent to the constant conditions. Solution: When there are constant tables only, evaluate only the conditions that reference outer fields, because the constant conditions are already checked, and the where clause doesn't have other conditions than constant ones, and outer referencing ones. The fix for lp:894397 also fixes lp:833777.
-
unknown authored
The problem was that when we have single row subquery with no rows Item_cache(es) which represent result row was not null and being requested via element_index() returned random value. The fix is setting all Item_cache(es) in NULL before executing the query (reset() method) which guaranty NULL value of whole query or its elements requested in any way if no rows was found. set_null() method was added to Item_cache to guaranty correct NULL value in case of reseting the cache.
-
- 26 Nov, 2011 2 commits
-
-
Igor Babaev authored
and 'derived_with_keys'. Now they are set on by default.
-
Sergey Petrunya authored
-
- 25 Nov, 2011 8 commits
-
-
Sergey Petrunya authored
- Make functions that operate on SJ_TMP_TABLE be member functions - Make Loose_scan_opt data members private
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Sergey Petrunya authored
-
Igor Babaev authored
-
Sergey Petrunya authored
- Make EXPLAIN display "Start temporary" at the start of the fanout (it used to display at the first table whose rowid gets into temp. table which is not that useful for the user) - Updated test results (all checked)
-
- 24 Nov, 2011 5 commits
-
-
-
unknown authored
The patch also fixes an unrelated compiler warning. Analysis: The temporary table created during SJ-materialization might be used for sorting for a group by operation. The sort buffers for this internal temporary table were not cleared by the execution code after each subquery re-execution. This resulted in a memory leak detected by valgrind. Solution: Cleanup the sort buffers for the semijon tables as well. sql/item_subselect.cc: - Fix a compiler warning and add logic to revert to table scan partial match when there are more rows in the materialized subquery than there can be bits in the NULL bitmap index used for partial matching. sql/opt_subselect.cc: - Fixed a memory leak detected by valgrind
-
Igor Babaev authored
-
unknown authored
Stop attempts to apply IN/ALL/ANY optimizations to so called "fake_select" (used for ordering and filtering results of union) in union subquery execution.
-
Alexey Botchkov authored
per-file comments: mysql-test/t/gis-precise.test number-to-string conversion differs on Windows. Have to tolerate this while GIS data is stored in doubles. sql/spatial.cc prev_x initialization added.
-
- 23 Nov, 2011 2 commits
-
-
unknown authored
Analysis: The bug is a result of an incomplete fix for bug lp:869036. That fix didn't take into account that there may be a case when ther are no NULLs in the materialized subquery, however all columns without NULLs may not be grouped in the only non-null index. This is the case when the left subquery expression has nullable columns. Solution: The patch handles two missing sub-cases of the case when there are no value (non-null matches) for any outer expression, and there are both NULLs and non-NUll values in the outer reference. a) If the materialized subquery contains no NULLs there cannot be a partial match, because there are no NULLs in those columns where the outer reference has no NULLs. b) If the materialized subquery contains NULLs, but there exists a column, such that its corresponding outer expression has no NULL, and this column also has no NULL. Then there cannot be a partial match either.
-
Sergey Petrunya authored
- Break down POSITION/advance_sj_state() into four classes representing potential semi-join strategies. - Treat all strategies uniformly (before, DuplicateWeedout was special as it was the catch-all strategy. Now, we're still relying on it to be the catch-all, but are able to function,e.g. with firstmatch=on,duplicate_weedout=off. - Update test results (checked)
-
- 22 Nov, 2011 3 commits
-
-
Alexey Botchkov authored
-
Alexey Botchkov authored
So removed.
-
unknown authored
-
- 21 Nov, 2011 9 commits
-
-
unknown authored
-
unknown authored
the depth of subquery nestedness to less than 31 (sizeof(ulong)-1).
-
Igor Babaev authored
-
Igor Babaev authored
This bug in the function Loose_scan_opt::check_ref_access_part1 could lead to choosing an invalid execution plan employing a loose scan access to a semi-join table even in the cases when such access could not be used at all. This could result in wrong answers for some queries with IN subqueries.
-
unknown authored
Analysis: The optimizer distinguishes two kinds of 'constant' conditions: expensive ones, and non-expensive ones. The non-expensive conditions are evaluated inside make_join_select(), and if false, already the optimizer detects empty query results. In order to avoid arbitrarily expensive optimization, the evaluation of expensive constant conditions is delayed until execution. These conditions are attached to JOIN::exec_const_cond and evaluated in the beginning of JOIN::exec. The relevant execution logic is: JOIN::exec() { if (! join->exec_const_cond->val_int()) { produce an empty result; stop execution } continue execution execute the original WHERE clause (that contains exec_const_cond) ... } As a result, when an expensive constant condition is TRUE, it is evaluated twice - once through JOIN::exec_const_cond, and once through JOIN::cond. When the expensive constant condition is a subquery, predicate, the subquery is evaluated twice. If we have many levels of subqueries, this logic results in a chain of recursive subquery executions that walk a perfect binary tree. The result is that for subquries with depth N, JOIN::exec is executed O(2^N) times. Solution: Notice that the second execution of the constant conditions happens inside do_select(), in the branch: if (join->table_count == join->const_tables) { ... } In this case exec_const_cond is equivalent to the whole WHERE clause, therefore the WHERE clause has already been checked in the beginnig of JOIN::exec, and has been found to be true. The bug is addressed by not evaluating the WHERE clause if there was exec_const_conds, and it was TRUE.
-
unknown authored
-
Igor Babaev authored
set to 'on' by default.
-
unknown authored
-
Igor Babaev authored
-
- 20 Nov, 2011 2 commits
-
-
Igor Babaev authored
A non-first execution of a prepared statement missed a call of the TABLE_LIST::process_index_hints() method in the code of the function setup_tables(). At some scenarios this could lead to the choice of a quite inefficient execution plan for the base query of the prepared statement.
-
Alexey Botchkov authored
Checks for thd->killed state added to the long loops in geometry calculations. per-file comments: sql/gcalc_slicescan.cc Fix for bug #809849 spatial operations must be KILL-able. checks for TERMINATED_STATE added. sql/gcalc_slicescan.h Fix for bug #809849 spatial operations must be KILL-able. defines added to include checks for termination in the library. sql/gcalc_tools.cc Fix for bug #809849 spatial operations must be KILL-able. checks for TERMINATED_STATE added. sql/gcalc_tools.h Fix for bug #809849 spatial operations must be KILL-able. TERMINATED_STATE pointers added. sql/item_geofunc.cc Fix for bug #809849 spatial operations must be KILL-able. sql/item_geofunc.h Fix for bug #809849 spatial operations must be KILL-able.
-
- 18 Nov, 2011 2 commits
-
-
Igor Babaev authored
This bug in the function setup_semijoin_dups_elimination() could lead to invalid choice of the sequence of tables for which semi-join duplicate elimination was applied.
-
Igor Babaev authored
Due to this bug the function SEL_IMERGE::or_sel_tree_with_checks() could build an inconsistent merge tree if one of the SEL_TREEs in the resulting index merge happened to contain a full key range. This could trigger an assertion failure.
-