- 07 Dec, 2011 4 commits
-
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- opt_sum_query() should not assume that join tables from sj-materialization have known numbers of rows.
-
Sergey Petrunya authored
-
Sergey Petrunya authored
- Part2: safety and code cleanup
-
- 06 Dec, 2011 5 commits
-
-
Igor Babaev authored
The execution plan cannot use sorting on the first table from the sequence of the joined tables if it plans to employ the block-based hash join algorithm.
-
Sergey Petrunya authored
- Part 1 of the fix: for semi-join merged subqueries, calling child_join->optimize() until we're done with all PS-lifetime optimizations in the parent.
-
Igor Babaev authored
The optimizer must ignore any possible hash join key when looking for the query execution plan with join_cache_level set to 0.
-
Igor Babaev authored
-
Igor Babaev authored
-
- 05 Dec, 2011 3 commits
-
-
Sergey Petrunya authored
- Make create_tmp_table() set KEY_PART_INFO attributes for the keys it creates. This wasn't needed before but is needed now, when temp. tables that are results of SJ-Materialization are being used for joins. This particular bug depended on HA_VAR_LENGTH_PART being set, but also added code to set HA_BLOB_PART and HA_NULL_PART when appropriate.
-
Igor Babaev authored
KEYUSE elements for a possible hash join key are not sorted by field numbers of the second table T of the hash join operation. Besides some of these KEYUSE elements cannot be used to build any key as their key expressions depend on the tables that are planned to be accessed after the table T. The code before the patch did not take this into account and, as a result, execition of a query the employing block-based hash join algorithm could cause a crash or return a wrong result set.
-
Sergey Petrunya authored
-
- 04 Dec, 2011 2 commits
-
-
Sergey Petrunya authored
in EXPLAIN as select_type==MATERIALIZED. Before, we had select_type==SUBQUERY and it was difficult to tell materialized subqueries from uncorrelated scalar-context subqueries.
-
Igor Babaev authored
If has been decided that the first match strategy is to be used to join table T from a semi-join nest while no buffer can be employed to join this table then no join buffer can be used to join any table in the join sequence between the first one belonging to the semi-join nest and table T.
-
- 01 Dec, 2011 3 commits
-
-
Michael Widenius authored
Added some file to ignore
-
Michael Widenius authored
-
Michael Widenius authored
Increased number of locks in thr_lock (used only when testing) include/my_global.h: Patch for CYGWIN mysys/my_getsystime.c: Patch for CYGWIN mysys/thr_lock.c: Increase number of locks for testing
-
- 30 Nov, 2011 2 commits
-
-
Igor Babaev authored
The tables from the same semi-join or outer join nest cannot use join buffers if in the join sequence of the query execution plan they are separated by a table that is planned to be joined without usage of a join buffer.
-
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.
-