The function was adjusted to be able to aggregate
the counters of the merged elements.
Before this change it was not possible to guarantee the correctness
of the counters passed to the the call-back parameter walk_action.
As a result, when some elements of a Unique object were flushed into
disk the function passed to merge_walk() as the call-back parameter
could return wrong counters of elements. This could lead to building
wrong histograms.
Don't try to a histogram if it is not read into the cache for statistical data.
It may happen so if optimizer_use_condition_selectivity is set to 3. This
setting orders the optimizer not use histograms to calculate selectivity.
When performing the range analysis for a conjunction the function
calculate_cond_selectivity_for_table should take in to account that
the analysis of some conjuncts may return SEL_ARG::IMPOSSIBLE.
mysqltest: At line 477: query 'show explain for $thr2' failed: 1933: Target is not running an EXPLAINable command
After the fix for MDEV-4144, subquery with WHERE pk= (select ...) became a degenerate, constant
SELECT. It is not executed in normal way anymore, so it is not possible to catch it in-execution.
One of them is quite serious: the function table_cond_selectivity used
the TABLE_REF structure for ref/eq_ref access methods as if they had been
filled. In fact these structure are filled after the best execution plan
has been chosen.
The other bugs happened due to:
- an erroneous attempt at get statistics on the result of materialization
of a view
- incorrect handling of ranges with no left/right limits when calculating
selectivity of range conditions on non-indexed columns
- lack of cleanup for some newly introduced fields
Analysis:
The reason for the inefficent plan was that Item_subselect::is_expensive()
didn't detect the special case when a subquery was optimized, but had no
join plan because it either has no table, or its tables have been optimized
away, or the optimizer detected that the result set is empty.
Solution:
Identify the special cases above in the Item_subselect::is_expensive(),
and consider such degenerate subqueries inexpensive.
This bug was introduced by the patch for WL#3220.
If the memory allocated for the tree to store unique elements
to be counted is not big enough to include all of them then
an external file is used to store the elements.
The unique elements are guaranteed not to be nulls. So, when
reading them from the file we don't have to care about the null
flags of the read values. However, we should remove the flag
at the very beginning of the process. If we don't do it and
if the last value written into the record buffer for the field
whose distinct values needs to be counted happens to be null,
then all values read from the file are considered to be nulls
and are not counted in.
The fix does not remove a possible null flag for the read values.
Rather it just counts the values in the same way it was done
before WL #3220.
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.
Additional fixes for possible overflows in length-related
calculations in 'spatial' implementations.
Checks added to the ::get_data_size() methods.
max_n_points decreased to occupy less 2G size. An
object of that size is practically inoperable anyway.
Item_func_make_set wasn't taking into account the first argument when
calculating maybe_null.
sql/item_strfunc.cc:
rewrite Item_func_make_set, removing separate storage of the first argument
sql/item_strfunc.h:
rewrite Item_func_make_set, removing separate storage of the first argument
with decimals=NOT_FIXED_DEC it is possible to have 'decimals' larger
than 'max_length', it's not an error for temporal functions.
But when Item_func_numhybrid converts the value to DECIMAL_RESULT,
it must limit 'decimals' to be a valid scale of a decimal number.
STRAIGHT_JOIN couldn't be combined with NATURAL or USING(),
INNER JOIN not with NATURAL (MDEV-4271, MySQL Bug #35268)
Separate rules existed for "natural" (non-outer) joins and
for STRAIGHT_JOIN, with the only difference code wise being
that with STRAIGHT_JOIN the "straight" property of the right
side table was set before calling the appropriate add_...()
function.
The "natural_join" parser rule has now been extended to also
accept STRAIGHT_JOIN, and the rule result value is set to
1 for straight joins, 0 otherwise, so acting as a "straight"
flag that can directly be assigned to the "straight" property
of the right side table.
The rule parsing NATURAL JOIN was hard coded to accept just
this keyword combination, without support for either
STRAIGHT_JOIN or the optional INNER.
The "natural_join" rule has now been split up in an inner
"inner_join" rule that matches the JOIN, INNER JOIN and
STRAIGHT_JOIN cases while "natural_join" also matches
CROSS JOIN.
The NATURAL rule has been changed to accept "inner_join"
instead of just JOIN, so now NATURAL STRAIGHT_JOIN and
NATURAL INNER JOIN also work as expected.
As a side effect the removal of the duplciated rules
for STRAIGHT_JOIN handling has reduced the shift/reduce
conflict count by one.
mysql-test/r/join.result:
Added new test cases
mysql-test/t/join.test:
Added new test cases
sql/sql_yacc.yy:
The "natural_join" parser rule was extended to also accept STRAIGHT_JOIN
NATURAL STRAIGHT_JOIN and NATURAL INNER JOIN also now work as expected
Flip the switch and create Item_cache based on the argument's cmp_type, not argument's result_type().
Fix subselect_engine to calculate cmp_type correctly
sql/item_subselect.h:
mdev:4284
mysql-test/r/keywords.result:
Test that option works as table/column/variable
mysql-test/suite/funcs_1/r/storedproc.result:
OPTION is now a valid identifier
mysql-test/suite/funcs_1/t/storedproc.test:
OPTION is now a valid identifier
mysql-test/t/keywords.test:
Test that option works as table/column/variable
sql/sql_yacc.yy:
OPTION is now a valid identifier
get_datetime_value() should not double-cache its own Item_cache_temporal items,
but it *should* cache other Item_cache items, such as Item_cache_str.
sql/item.h:
shortcut, to avoid going through the switch in Item::cmp_type()
sql/item_cmpfunc.cc:
even if the item is Item_cache_str - it still needs to be converted and cached.
sql/item_timefunc.h:
all descendants of Item_temporal_func always have cmp_type==TIME_RESULT.
Even Item_date_add_interval, that might have field_type == MYSQL_TYPE_STRING.
