- The problem was with execution strategy for cases where FirstMatch's inner tables
  were interleaved with outer-uncorrelated tables.
- I was unable to find any cases where such join orders would be practically useful,
  so fixed it by disabling them.

BUG#951937: Wrong result (missing rows) with semijoin+materialization, IN subquery, InnoDB, TEMPTABLE view
- Fix equality propagation to work with SJM nests and OR clauses (full descirption of problem and
  solution in the comment in the patch)
(The second commit with post-review fixes)

- The problem was that
  = we've picked a LooseScan that used full index scan (tab->type==JT_ALL) on certain index.
  = there was also a quick select (tab->quick!=NULL), that used other indexes.
  = some old code assumes that (tab->type==JT_ALL && tab->quick) -> means that the
    quick select should be used, which is not true.
Fixed by discarding the quick select as soon as we know we're using LooseScan
without using the quick select.

Improve filesort performance for small sorts: Don't write pointers to records that we will never use.

- Don't call update_virtual_fields() if table->vfield is not set
- Don't prealloc memory for in open_tables() as this is very seldom used.


sql/records.cc:
  Don't call update_virtual_fields() if table->vfield is not set
sql/sql_base.cc:
  Don't prealloc memory for in open_tables() as this is very seldom used.
  Don't call update_virtual_fields() if table->vfield is not set
sql/sql_delete.cc:
  Don't call update_virtual_fields() if table->vfield is not set
sql/sql_handler.cc:
  Don't call update_virtual_fields() if table->vfield is not set
sql/sql_join_cache.cc:
  Don't call update_virtual_fields() if table->vfield is not set
  Move some frequent values to local variables
sql/sql_table.cc:
  Don't call update_virtual_fields() if table->vfield is not set
sql/sql_update.cc:
  Don't call update_virtual_fields() if table->vfield is not set
sql/table.cc:
  Assert if update_virtual_fields is called with wrong parameters

- Remove all references of MAX_TABLES from JOIN struct and make these dynamic
- Updated Join_plan_state to allocate just as many elements as it's needed


sql/opt_subselect.cc:
  Optimized version of Join_plan_state
sql/sql_select.cc:
  Set join->positions and join->best_positions dynamicly
  Don't call update_virtual_fields() if table->vfield is not set.
sql/sql_select.h:
  Remove all references of MAX_TABLES from JOIN struct and Join_plan_state and make these dynamic

- Optimize away calls to hp_rec_hashnr() by cashing hash
- Try to get more rows / block (to minimize overhead of HP_PTRS) in HEAP tables.


storage/heap/_check.c:
  Optimize away calls to hp_rec_hashnr() by cashing hash.
  Print cleanups
storage/heap/heapdef.h:
  Added place to hold calculated hash value for row
storage/heap/hp_create.c:
  Try to get more rows / block (to minimize overhead of HP_PTRS)
storage/heap/hp_delete.c:
  Optimize away calls to hp_rec_hashnr() by cashing hash.
storage/heap/hp_hash.c:
  Optimize away calls to hp_rec_hashnr() by cashing hash.
  Remove some not needed DBUG_PRINT
storage/heap/hp_test2.c:
  Increased max table size as now heap tables takes a bit more space (a few %)
storage/heap/hp_write.c:
  Optimize away calls to hp_rec_hashnr() by cashing hash.
  Remove duplicated code
  More DBUG_PRINT
storage/maria/ma_create.c:
  More DBUG_PRINT

If the first component of a ref key happened to be a constant appeared
after constant row substitution then no store_key element should be
created for such a component. Yet create_ref_for_key() erroneously could
create such an element that caused construction of invalid ref keys and
wrong results for some joins.

lp:933959 Assertion `0' failed in net_end_statement(THD*) on concurrent SELECT FROM I_S.INNODB_SYS_INDEXES and ALTER TABLE

Workaround: report a generic error if an I_S plugin failed silently.

mark the corresponding I_S table as OPTIMIZE_I_S_TABLE, to let the I_S optimizer
figure out whether files need to be opened, and don't open the tables unless
I_S optimizer says so.

This bug in the constructor SEL_IMERGE::SEL_IMERGE could 
cause huge excessive memory requests.

- Take into account that there may exist Item_field objects with context==NULL.

BUG#952372: Server crashes on 2nd execution of PS in find_field_in_tables with semijoin+materialization
- The problem was that convert_subq_to_jtbm() attached the semi-join
  TABLE_LIST object into the wrong list: they used to attach it to the 
  end of parent_lex->leaf_tables.head()->next_local->...->next_local.
  This was apparently inccorect, as one can construct an example where 
  JTBM nest is attached to a table that is inside some mergeable VIEW, which
  breaks (causes crash) for name resolution on the subsequent statement
  re-execution.
- Solution: Attach to the "right" list. The "wording" was copied from
  st_select_lex::handle_derived.

use vsnprintf()
use write() on windows, not WriteFile or fwrite()
localtime_r is still a problem

Do not call, directly or indirectly, SQL_SELECT::test_quick_select()
for derived materialized tables / views when optimizing joins referring
to these tables / views to get cost estimates of materialization.
The current code does not create B-tree indexes for materialized 
derived tables / views. So now it's not possible to get any estimates
for ranges conditions over the results of the materialization.

The function mysql_derived_create() must take into account the fact
that array of the KEY structures specifying the keys over a derived
table / view may be moved after the optimization phase if the
derived table / view  is materialized.

Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
Change ha_archive::unpack_row() to detect wrong field lengths.
Replication code changed to detect wrong field information in events.


mysql-test/r/archive.result:
  dded test case for lp:917689
sql/field.cc:
  Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
  Removed not used 'unpack_key' functions.
sql/field.h:
  Added 'from_end' as extra parameter to Field::unpack() to detect wrong from data.
  Removed not used 'unpack_key' functions.
  Removed some not needed unpack() functions.
sql/filesort.cc:
  Added buffer end parameter to unpack_addon_fields()
sql/log_event.h:
  Added end of buffer argument to unpack_row()
sql/log_event_old.cc:
  Added end of buffer argument to unpack_row()
sql/log_event_old.h:
  Added end of buffer argument to unpack_row()
sql/records.cc:
  Added buffer end parameter to unpack_addon_fields()
sql/rpl_record.cc:
  Added end of buffer argument to unpack_row()
  Added detection of wrong field information in events
sql/rpl_record.h:
  Added end of buffer argument to unpack_row()
sql/rpl_record_old.cc:
  Added end of buffer argument to unpack_row()
  Added detection of wrong field information in events
sql/rpl_record_old.h:
  Added end of buffer argument to unpack_row()
sql/table.h:
  Added buffer end parameter to unpack()
storage/archive/ha_archive.cc:
  Change ha_archive::unpack_row() to detect wrong field lengths.
  This fixes lp:917689

- The bug would show up 
   - when using PS (so that we get re-execution)
   - the left_expr of the subquery is a reference to viewname.column_name, so that it crashes
      when one tries to use it without having called fix_fields for it.
   - when using SJ-Materialization, which makes use of sj_subq_pred->left_expr expression

- The fix is to have setup_conds() fix sj_subq_pred->left_expr for semi-join nests it finds.

This bug was introduced into mariadb 5.2 in the December 2010 with
the patch that added a new engine property: the ability to support
virtual columns.    
As a result of this bug the information from frm files for tables 
that contained virtual columns did not appear in the information schema
tables.

Added test case for lp:905782 "Assertion `pageno < ((1ULL) << 40)' failed at ma_pagecache.c:3438: pagecache_read or table corruption on INSERT into a ucs2 table"
The orignal bug has been fixed earlier

If in the where clause of the a query some comparison conditions on the
field under a MIN/MAX aggregate function contained constants whose sizes
exceeded the size of the field then the query could return a wrong result
when the optimizer had chosen to apply the MIN/MAX optimization.
With such conditions the MIN/MAX optimization still could be applied, yet
it would require a more thorough analysis of the keys built to find
the value of MIN/MAX aggregate functions with index look-ups.   
The current patch just prohibits using the MIN/MAX optimization in this
situation.

The function create_hj_key_for_table() that builds the descriptor of
the hash join key to access a table of a materialized subquery must
ignore any equi-join predicate depending on the tables not belonging
to the subquery.