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.
During server shutdown, we need to wait for binlog checkpointing to
finish in the binlog background thread before closing the binlog.
This was not done, so we could get assert and failure to finish the
final binlog checkpoint if shutdown happened in the middle.
-Change my_rnd() slightly to make it safer if two threads use it at the same time.
-Avoid some sprintf and strmov in vio.
-Changed thread_count to be automaticly incremented (instead of under LOCK_thread_count).
-Thread cache now uses LOCK_thread_cache instead of LOCK_thread_count.
-Moved delete thd out from LOCK_thread_count.
-Save some mysql_cond_broadcast(&COND_thread_count) calls.
-Removed call to getsockname() during connect.
-Initialize random generator without locks.
Other things:
-Fixed test cases that depends on changes for LOCK_grant
-Added thread_safe_decrement32() and thread_safe_increment32()
-Removed sql_rnd_with_mutex() and get_thread_running()
-In check_table_access() don't lock LOCK_grant if we can resolve the grant with user or db level grants (the normal case).
-Don't use a lock for setting THD->query_id.
-Fixed bug where thd->set_query_id() could be set to same value by multiple threads.
Thanks to Yoshinori Matsunobu for the benchmark of connection speed and to
Domas Mituzas for the inspiration for many of the fixes.
include/violite.h:
Change desc to a string pointer
mysql-test/suite/perfschema/r/all_instances.result:
Added new mutex
mysql-test/suite/perfschema/t/func_mutex.test:
Test for LOCK_system_variables_hash instead of LOCK_grant, as LOCK_grant is not anymore always taken for SELECT's.
mysys/my_gethwaddr.c:
More DBUG
mysys/my_rnd.c:
Change my_rnd() slightly to make it safer if two threads use it at the same time.
sql/event_scheduler.cc:
Changed thread_count to be automically incremented
Moved some safe things out from LOCK_thread_count.
Simplify deleting of THD for running thread.
sql/mysqld.cc:
Changed thread_count to be automically incremented
Thread cache now uses LOCK_thread_cache instead of LOCK_thread_count
Added delete_running_thd()
Moved delete thd out from LOCK_thread_count
More DBUG
Only call mysql_cond_broadcast(&COND_thread_count) if thread_count is 0
Removed call to getsockname() (old not anymore needed check)
sql/mysqld.h:
Removed sql_rnd_with_mutex() (not needed anymore)
Removed not used function get_thread_running()
Added thread_safe_decrement32() and thread_safe_increment32()
Simplified dec_thread_running() and inc_thread_running()
next_query_id() should return the original value for global_query_id, not the next one.
(Bug introduced with MySQL 5.5 merge).
sql/sql_acl.cc:
In check_table_access() don't lock LOCK_grant if we can resolve the grant with user or db level grants (the normal case).
sql/sql_class.cc:
Removed thd_lock_thread_count() and thd_unlock_thread_count()
Initialize random generator without locks
Don't use a lock for setting THD->query_id.
(This is only accessed by thread owning the THD)
sql/sql_class.h:
Don't use a lock for setting THD->query_id.
sql/sql_insert.cc:
Changed thread_count to be automically incremented
sql/sql_parse.cc:
Changed thread_count to be automically incremented
Fixed bug where thd->set_query_id() could be set to same value by multiple threads.
vio/vio.c:
Don't generate 'desc' with sprintf/strmov. Assign a pointer instead.
(Good enough as this is just for debugging)
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.
