mirror of
https://github.com/MariaDB/server.git
synced 2025-01-18 21:12:26 +01:00
0c66f4a64a
Some collations were causing IBMDB2I to report inaccurate key range estimations to the optimizer for LIKE clauses that select substrings. This can be seen by running EXPLAIN. This problem primarily affects multi-byte and unicode character sets. This patch involves substantial changes to several modules. There are a number of problems with the character set and collation handling. These problems have been or are being fixed, and a comprehensive test has been included which should provide much better coverage than there was before. This test is enabled only for IBM i 6.1, because that version has support for the greatest number of collations. mysql-test/suite/ibmdb2i/r/ibmdb2i_collations.result: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I result file for test case. mysql-test/suite/ibmdb2i/t/ibmdb2i_collations.test: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Tests for character sets and collations. This test is enabled only for IBM i 6.1, because that version has support for the greatest number of collations. storage/ibmdb2i/db2i_conversion.cc: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I - Added support in convertFieldChars to enable records_in_range to determine how many substitute characters were inserted and to suppress conversion warnings. - Fixed bug which was causing all multi-byte and Unicode fields to be created as UTF16 (CCSID 1200) fields in DB2. The corrected code will now create UCS2 fields as UCS2 (CCSID 13488), UTF8 fields (except for utf8_general_ci) as UTF8 (CCSID 1208), and all other multi-byte or Unicode fields as UTF16. This will only affect tables that are newly created through the IBMDB2I storage engine. Existing IBMDB2I tables will retain the original CCSID until recreated. The existing behavior is believed to be functionally correct, but it may negatively impact performance by causing unnecessary character conversion. Additionally, users accessing IBMDB2I tables through DB2 should be aware that mixing tables created before and after this change may require extra type casts or other workarounds. For this reason, users who have existing IBMDB2I tables using a Unicode collation other than utf8_general_ci are encouraged to recreate their tables (e.g. ALTER TABLE t1 ENGINE=IBMDB2I) in order to get the updated CCSIDs associated with their DB2 tables. - Improved error reporting for unsupported character sets by forcing a check for the iconv conversion table at table creation time, rather than at data access time. storage/ibmdb2i/db2i_myconv.h: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Fix to set errno when iconv fails. storage/ibmdb2i/db2i_rir.cc: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I Significant improvements were made to the records_in_range code that handles partial length string data in keys for optimizer plan estimation. Previously, to obtain an estimate for a partial key value, the implementation would perform any necessary character conversion and then attempt to determine the unpadded length of the partial key by searching for the minimum or maximum sort character. While this algorithm was sufficient for most single-byte character sets, it did not treat Unicode and multi-byte strings correctly. Furthermore, due to an operating system limitation, partial keys having UTF8 collations (ICU sort sequences in DB2) could not be estimated with this method. With this patch, the code no longer attempts to explicitly determine the unpadded length of the key. Instead, the entire key is converted (if necessary), including padding, and then passed to the operating system for estimation. Depending on the source and target character sets and collations, additional logic is required to correctly handle cases in which MySQL uses unconvertible or differently -weighted values to pad the key. The bulk of the patch exists to implement this additional logic. storage/ibmdb2i/ha_ibmdb2i.h: Bug#45803 Inaccurate estimates for partial key values with IBMDB2I The convertFieldChars declaration was updated to support additional optional behaviors. |
||
---|---|---|
.. | ||
collections | ||
extra | ||
include | ||
lib | ||
r | ||
std_data | ||
suite | ||
t | ||
Makefile.am | ||
mysql-stress-test.pl | ||
mysql-test-run.pl | ||
purify.supp | ||
README | ||
README.gcov | ||
README.stress | ||
valgrind.supp |
This directory contains a test suite for the MySQL daemon. To run the currently existing test cases, simply execute ./mysql-test-run in this directory. It will fire up the newly built mysqld and test it. Note that you do not have to have to do "make install", and you could actually have a co-existing MySQL installation. The tests will not conflict with it. All tests must pass. If one or more of them fail on your system, please read the following manual section for instructions on how to report the problem: http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html If you want to use an already running MySQL server for specific tests, use the --extern option to mysql-test-run. Please note that in this mode, the test suite expects you to provide the names of the tests to run. For example, here is the command to run the "alias" and "analyze" tests with an external server: mysql-test-run --extern alias analyze To match your setup, you might also need to provide --socket, --user, and other relevant options. With no test cases named on the command line, mysql-test-run falls back to the normal "non-extern" behavior. The reason for this is that some tests cannot run with an external server. You can create your own test cases. To create a test case, create a new file in the t subdirectory using a text editor. The file should have a .test extension. For example: xemacs t/test_case_name.test In the file, put a set of SQL statements that create some tables, load test data, and run some queries to manipulate it. We would appreciate it if you name your test tables t1, t2, t3 ... (to not conflict too much with existing tables). Your test should begin by dropping the tables you are going to create and end by dropping them again. This ensures that you can run the test over and over again. If you are using mysqltest commands (like result file names) in your test case, you should create the result file as follows: mysql-test-run --record test_case_name or mysqltest --record < t/test_case_name.test If you only have a simple test cases consisting of SQL statements and comments, you can create the test case in one of the following ways: mysql-test-run --record test_case_name mysql test < t/test_case_name.test > r/test_case_name.result mysqltest --record --record-file=r/test_case_name.result < t/test_case_name.test When this is done, take a look at r/test_case_name.result - If the result is incorrect, you have found a bug. In this case, you should edit the test result to the correct results so that we can verify that the bug is corrected in future releases. To submit your test case, put your .test file and .result file(s) into a tar.gz archive, add a README that explains the problem, ftp the archive to ftp://support.mysql.com/pub/mysql/secret/ and send a mail to bugs@lists.mysql.com