Problem: creating an rb-tree key we store length (2 bytes) before the actual data for
varchar key parts. The fact was missed for NULL key parts, when we set NULL byte and
skip the rest.
Fix: take into account the length of the varchar key parts for NULLs.
DELETE query against memory table with btree index may remove
not all matching rows. This happens only when DELETE uses
index read method to find matching rows. E.g. for queries
like DELETE FROM t1 WHERE a=1.
Fixed by reverting fix for BUG9719 and applying proper solution.
causes incorrect duplicate entries
Keys for BTREE indexes on ENUM and SET columns of MEMORY tables
with character set UTF8 were computed incorrectly. Many
different column values got the same key value.
Apart of possible performance problems, it made unique indexes
of this type unusable because it rejected many different
values as duplicates.
The problem was that multibyte character detection was tried
on the internal numeric column value. Many values were not
identified as characters. Their key value became blank filled.
Thanks to Alexander Barkov and Ramil Kalimullin for the patch,
which sets the character set of ENUM and SET key segments to
the pseudo binary character set.
Using a MEMORY table BTREE index for scanning for updatable rows
could lead to an infinite loop.
Everytime a key was inserted into a btree index, the position
in the index scan was cleared. The search started from the
beginning and found the same key again.
Now we do not clear the position on key insert an more.
Updating data in HEAP table with BTREE index results in wrong index_length
counter value, which keeps growing after each update.
When inserting new record into tree counter is incremented by:
sizeof(TREE_ELEMENT) + key_size + tree->size_of_element
But when deleting element from tree it doesn't decrement counter by key_size:
sizeof(TREE_ELEMENT) + tree->size_of_element
This fix makes accurate allocated memory counter for tree. That is
decrease counter by key_size when deleting tree element.
- If number of records in table is 4, the calculated cost for using "index" and "range" become so close so that any rounding errors becomes visible.
- Added one more record to the tables for heap test and expoect "range" to be selected
- Decrease number of records in t1 for range and expect "index" to be choosen.
Fixed (together with Guilhem) bugs in mysqlbinlog regarding --offset
Prefix addresses with 0x for easier comparisons of debug logs
Fixed problem where MySQL choosed index-read even if there would be a much better range on the same index
This fix changed some 'index' queries to 'range' queries in the test suite
Don't create 'dummy' WHERE clause for trivial WHERE clauses where we can remove the WHERE clause.
This fix removed of a lot of 'Using where' notes in the test suite.
Give NOTE instead of WARNING if table/function doesn't exists when using DROP IF EXISTS
Give NOTE instead of WARNING for safe field-type conversions
If cost(full_scan_on_shortest_covering_index) < cost(best_range_scan) < cost(full_table_scan)
use full_scan_on_shortest_covering_index
(before this fix best_range_scan was used)
Don't read character set files if we are using only the default charset. In most cases the user will not anymore get a warning about missing character set files
Compare strings with space extend instead of space strip. Now the following comparisons holds: "a" == "a " and "a\t" < "a". (Bug #3152).
Note: Because of the above fix, one has to do a REPAIR on any table that has an ascii character < 32 last in a CHAR/VARCHAR/TEXT columns.
bmove_allign -> bmove_align
Added OLAP function ROLLUP
Split mysql_fix_privilege_tables to a script and a .sql data file
Added new (MEMROOT*) functions to avoid calling current_thd() when creating some common objects.
Added table_alias_charset, for easier --lower-case-table-name handling
Better SQL_MODE handling (Setting complex options also sets sub options)
New (faster) assembler string functions for x86
