"
revision-id: sanja@askmonty.org-20110511110948-4kdevwzomvk56y1w
committer: sanja@askmonty.org
branch nick: work-maria-5.1-CREATE-merge
timestamp: Wed 2011-05-11 14:09:48 +0300
Bugfix: New table creation/renaming block added if old encoded table present
"
the old behavior was less inconsistent than the new one.
In the new one the error message was sometimes different (under LOCK TABLES e.g.),
and there were race conditions (if this CREATE happened when a concurrent ALTER
has renamed the old table away but haven't put the new table in place)
The old one was like "(when using old table names) for DML #mysql50# prefix
is optional, for DDL it's required".
* print "table doesn't exist in engine" when a table doesn't exist in the engine,
instead of "file not found" (if no file was involved)
* print a complete filename that cannot be found ('t1.MYI', not 't1')
* it's not an error for a DROP if a table doesn't exist in the engine (or some table
files cannot be found) - if the DROP succeeded regardless
and let open_binary_frm to parse it from the buffer, not a file.
this avoids jumping back in forth in the frm file, and doing
intermediate buffer mallocs.
after all engines have discovered their tables
side effect: correct alphabetical sorting as in ORDER BY ... COLLATE utf8_bin,
information_schema is no longer the first after find_files(),
tables like #mysql50#zzz are sorted first (as per table name),
not last (as per file name zzz).
* replace pointer acrobatics with a struct
* make sorting explicit: MY_DONT_SORT -> MY_WANT_SORT
(if you want something to be done - say it. fixes all places where
my_dir() was used without thinking)
* typo s/number_off_files/number_of_files/
* directory_file_name() doesn't need to be extern
* remove #ifdef __BORLANDC__
* ignore '.' and '..' entries
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.
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.
