- Merge with 5.3 (3)

(incorrect block size)

(less not-needed copies of key pages)

storage/maria/ma_rkey.c:
  Fixed wrong test if SEARCH_SAVE_BUFF should be set.
  Now we assume that if we are doing HA_READ_KEY_EXACT,
  we don't have to copy the last key buffer
  (in other words, it's not likely this will be followed
  by a read-next call)

Aria and MyISAM in create_internal_tmp_table_from_heap()
(safe, as duplicates are impossible).
This gives a HUGE speed boost!

sql/opt_subselect.cc:
  Fixed problem with wrong recinfo in create_duplicate_weedout_tmp_tabl()
  Tagged the table with 'no_rows' so that when we create the table on disk,
  we only store the index data. This gave us a major speedup!
sql/sql_select.cc:
  create_tmp_table_from_heap() now uses bulk_insert + repair_by_sort
  when creating Aria/MyISAM tables from HEAP tables.
  This gives a HUGE speed boost!
storage/maria/ha_maria.cc:
  Extended bulk_insert() to recreate UNIQUE keys for
  internal temporary tables
storage/maria/ma_open.c:
  Initialize m_info->lock.type properly for temporarly tables
  (needed for start_bulk_insert())
storage/maria/ma_write.c:
  Don't check uniques that are disabled
storage/myisam/ha_myisam.cc:
  Extended bulk_insert() to recreate UNIQUE keys for
  internal temporary tables.

This will also enable us in the future to collect statistics for
writes to internal tmp tables.

sql/handler.h:
  Added ha_write_tmp_row()
sql/opt_subselect.cc:
  ha_write_row -> ha_write_tmp_row
sql/sql_class.h:
  Added ha_write_tmp_row()
sql/sql_select.cc:
  ha_write_row -> ha_write_tmp_row

This makes the keys smaller (no row pointer) and gives us proper errors if we
use the table wrongly.

sql/sql_select.cc:
  Use NO_RECORD for tables that doesn't need row data.
storage/maria/Makefile.am:
  Added ma_norec.c
storage/maria/ma_check.c:
  Added support for NO_RECORD record format (don't store any row data)
storage/maria/ma_norec.c:
  Added support for NO_RECORD record format
storage/maria/ma_open.c:
  Added support for NO_RECORD record format
storage/maria/ma_search.c:
  Added support for 0 size row pointers (used with NO_RECORD)
storage/maria/ma_test1.c:
  Added testing of NO_RECORD record format.
storage/maria/maria_chk.c:
  Added support for NO_RECORD
storage/maria/maria_def.h:
  Added support for NO_RECORD
storage/maria/unittest/ma_test_all-t:
  Added testing of NO_RECORD record format

temptables, not "uniques", that are hash-based keys.

sql/sql_expression_cache.cc:
  Don't set uniques (we don't want or need an unique
  constraint on this table)

This was needed as the old code caused us to have LOTS of duplicate
hash values when used by optimizer.

include/m_ctype.h:
  Made my_hash_sort_bin() exernal
storage/maria/ma_unique.c:
  Better hash for packed numeric data for unique handling.
  This was needed as the old code caused us to have LOTS
  of duplicate hash values when used by optimizer.

mysys/my_handler.c:
  Fixed typo

Made sure that the optimal fields are used by TABLE_REF objects
when building index access keys to joined tables.
Fixed a bug in the template function that sorts the elements of
a list using the bubble sort algorithm. The bug caused poor
performance of the function. Also added an optimization that
skips comparison with the most heavy elements that has been 
already properly placed in the list.
Made the comparison of the fields belonging to the same Item_equal
more granular: fields belonging to the same table are also ordered
according to some rules.

An assertion failure was triggered for a 6-way join query that used two
join buffers.
The failure happened because every call of JOIN_CACHE::join_matching_records
saved and restored status of all tables that were accessed before the table
join_tab. It must do it only for those of them that follow the last table 
using a join buffer.

- Backport testcases
- We have a different fix because we've fixed part of the problem as part of fix for LPBUG#602574.

Backport testcase: BUG#45863 "Assertion failed: (fixed == 0), function fix_fields(), file item.cc, line 4448"
(The fix was backported with subquery code backport)

3150 Olav Sandstaa     2010-05-07
Test cases for the following "ICP for InnoDB" bugs:

Bug#40992 InnoDB: Crash when engine_condition_pushdown is on
Bug#35080 Innodb crash at mem_block_get_len line 72
Bug#41996 multi-table delete crashes server (InnoDB table)
Bug#43448 Server crashes on multi table delete with Innodb

All these bugs are duplicates of either one or both of Bug 43360 or 36981.

(backporting of olav@sun.com-20100226091930-qxvakxmcp6463t5w)

Test case backport for: Bug#42580 - Innodb's ORDER BY ..LIMIT returns no rows for null-safe operator <=> NULL

(the bug itself was fixed during the subquery code backport)

3723 oystein.grovlen@sun.com   2009-11-23
Bug#46548 (addendum)
Remove KEY::extra_length.  It is not in use.

Bug #45092: join buffer contains two blob columns one of which is used in the key employed to access the joined table

Date: Mon, 01 Nov 2010 15:15:25 -0000
3272 Roy Lyseng        2010-11-01
Bug#52068: Optimizer generates invalid semijoin materialization plan

When MaterializeScan semijoin strategy was used and there were one
or more outer dependent tables before the semijoin tables, the scan
over the materialized table was not properly reset for each row of
the prefix outer tables.

Example: suppose we have a join order:

  ot1 SJ-Mat-Scan(it2 it3)  ot4

Notice that this is called a MaterializeScan, even though there is an
outer table ahead of the materialized tables. Usually a MaterializeScan
has the outer tables after the materialized table, but this is
a special (but legal) case with outer dependent tables both before and
after the materialized table.

For each qualifying row from ot1, a new scan over the materialized
table must be set up. The code failed to do that, so all scans after
the first one returned zero rows from the materialized table.

- Cause: handler::in_range_check_pushed_down was not reset when a 
  command would call handler->idx_cond_push() without later calling
  handler->index_end().
- Fix: reset the variable in handler->reset(), too (like we do with other
  Index Condition Pushdown members).

When stored in a key buffer any varchar field has a length prefix
that always takes 2 bytes.

Added a test case for bug #695442 - a duplicate of bug 694092.

The bug was the result of a bad merge maria-5.2-wl21 -> 5.3.