"
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.
