From ba68b26ae93855a595efc8d80ccbb9b96bbdeb53 Mon Sep 17 00:00:00 2001 From: Alexander Barkov Date: Fri, 19 Nov 2010 20:15:47 +0300 Subject: Bug#58190 BETWEEN no longer uses indexes for date or datetime fields Regression introduced by WL#2649. Problem: queries with date/datetime columns did not use indexes: set names non_latin1_charset; select * from date_index_test where date_column between '2010-09-01' and '2010-10-01'; before WL#2649 indexes worked fine because charset of date/datetime columns was BINARY which always won. Fix: testing that collation of the operation matches collation of the field is only needed in case of "real" string data types. For DATE, DATETIME it's not needed. @ mysql-test/include/ctype_numconv.inc @ mysql-test/r/ctype_binary.result @ mysql-test/r/ctype_cp1251.result @ mysql-test/r/ctype_latin1.result @ mysql-test/r/ctype_ucs.result @ mysql-test/r/ctype_utf8.result Adding tests @ sql/field.h Adding new method Field_str::match_collation_to_optimize_range() for use in opt_range.cc to distinguish between "real string" types like CHAR, VARCHAR, TEXT (Field_string, Field_varstring, Field_blob) and "almost string" types DATE, TIME, DATETIME (Field_newdate, Field_datetime, Field_time, Field_timestamp) @ sql/opt_range.cc Using new method instead of checking result_type() against STRING result. Note: Another part of this problem (which is not regression) is submitted separately (see bug##58329). --- sql/opt_range.cc | 1 + 1 file changed, 1 insertion(+) (limited to 'sql/opt_range.cc') diff --git a/sql/opt_range.cc b/sql/opt_range.cc index ffff9e3f6c8..2ac860d25e3 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -5796,6 +5796,7 @@ get_mm_leaf(RANGE_OPT_PARAM *param, COND *conf_func, Field *field, */ if (field->result_type() == STRING_RESULT && + ((Field_str*) field)->match_collation_to_optimize_range() && value->result_type() == STRING_RESULT && key_part->image_type == Field::itRAW && ((Field_str*)field)->charset() != conf_func->compare_collation() && -- cgit v1.2.1 From 352ce1b596758403ab9d439b06267fec4d191a58 Mon Sep 17 00:00:00 2001 From: Georgi Kodinov Date: Wed, 8 Dec 2010 14:28:06 +0200 Subject: Bug #57954: BIT_AND function returns incorrect results when semijoin=on When setting the aggregate function as having no rows to report the function no_rows_in_result() was calling Item_sum::reset(). However this function in addition to cleaning up the aggregate value by calling aggregator_clear() was also adding the current value to the aggregate value by calling aggregator_add(). Fixed by making no_rows_in_result() to call aggregator_clear() directly. Renamed Item_sum::reset to Item_sum::reset_and_add() to and added a comment to avoid misinterpretation of what the function does. --- sql/opt_range.cc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'sql/opt_range.cc') diff --git a/sql/opt_range.cc b/sql/opt_range.cc index 2ac860d25e3..f39037e9db9 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -11391,7 +11391,7 @@ void QUICK_GROUP_MIN_MAX_SELECT::update_min_result() min_functions_it->rewind(); while ((min_func= (*min_functions_it)++)) - min_func->reset(); + min_func->reset_and_add(); } @@ -11423,7 +11423,7 @@ void QUICK_GROUP_MIN_MAX_SELECT::update_max_result() max_functions_it->rewind(); while ((max_func= (*max_functions_it)++)) - max_func->reset(); + max_func->reset_and_add(); } -- cgit v1.2.1 From 85323eda8a5823e4db1fa34dc998684b67e710b5 Mon Sep 17 00:00:00 2001 From: Kent Boortz Date: Tue, 28 Dec 2010 19:57:23 +0100 Subject: - Added/updated copyright headers - Removed files specific to compiling on OS/2 - Removed files specific to SCO Unix packaging - Removed "libmysqld/copyright", text is included in documentation - Removed LaTeX headers for NDB Doxygen documentation - Removed obsolete NDB files - Removed "mkisofs" binaries - Removed the "cvs2cl.pl" script - Changed a few GPL texts to use "program" instead of "library" --- sql/opt_range.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/opt_range.cc') diff --git a/sql/opt_range.cc b/sql/opt_range.cc index 35d1216387c..e62fff8329c 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -1,4 +1,4 @@ -/* Copyright (C) 2000-2006 MySQL AB +/* Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by -- cgit v1.2.1 From e0887df8e1127c0f1410b9d4ad61647cb5f93be2 Mon Sep 17 00:00:00 2001 From: Mattias Jonsson Date: Fri, 25 Mar 2011 12:36:02 +0100 Subject: Bug#11766249 bug#59316: PARTITIONING AND INDEX_MERGE MEMORY LEAK When executing row-ordered-retrieval index merge, the handler was cloned, but it used the wrong memory root, so instead of allocating memory on the thread/query's mem_root, it used the table's mem_root, resulting in non released memory in the table object, and was not freed until the table was closed. Solution was to ensure that memory used during cloning of a handler was allocated from the correct memory root. This was implemented by fixing handler::clone() to also take a name argument, so it can be used with partitioning. And in ha_partition only allocate the ha_partition's ref, and call the original ha_partition partitions clone() and set at cloned partitions. Fix of .bzrignore on Windows with VS 2010 --- sql/opt_range.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'sql/opt_range.cc') diff --git a/sql/opt_range.cc b/sql/opt_range.cc index 9edd4f58f04..fd71166dc23 100644 --- a/sql/opt_range.cc +++ b/sql/opt_range.cc @@ -1335,7 +1335,7 @@ int QUICK_RANGE_SELECT::init_ror_merged_scan(bool reuse_handler) } thd= head->in_use; - if (!(file= head->file->clone(thd->mem_root))) + if (!(file= head->file->clone(head->s->normalized_path.str, thd->mem_root))) { /* Manually set the error flag. Note: there seems to be quite a few -- cgit v1.2.1