list using a function
When executing dependent subqueries they are re-inited and re-exec() for
each row of the outer context.
The cause for the bug is that during subquery reinitialization/re-execution,
the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
and the local variable in 'sortorder' in create_sort_index(), which is
allocated by make_unireg_sortorder().
Care must be taken not to allocate anything into the thread's memory pool
while re-initializing query plan structures between subquery re-executions.
All such items mush be cached and reused because the thread's memory pool
is freed at the end of the whole query.
Note that they must be cached and reused even for queries that are not
otherwise cacheable because otherwise it will grow the thread's memory
pool every time a cacheable query is re-executed.
We provide additional members to the JOIN structure to store references
to the items that need to be cached.
mysql-test/r/subselect.result:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- test case
mysql-test/t/subselect.test:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- test case
sql/mysql_priv.h:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the entities allocated in the threads memory pool by
JOIN::exec ().
sql/sql_delete.cc:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's
memory pool by JOIN::exec ().
sql/sql_select.cc:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's
memory pool by JOIN::exec ().
sql/sql_select.h:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's
memory pool by JOIN::exec ().
sql/sql_table.cc:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's
memory pool by JOIN::exec ().
sql/sql_update.cc:
Bug#21798: memory leak during query execution with subquery in column
list using a function
- cache the SORT_ORDER, TABLE * and JOIN_TAB allocated in the thread's
memory pool by JOIN::exec ().
list using a function
When executing dependent subqueries they are re-inited and re-exec() for
each row of the outer context.
The cause for the bug is that during subquery reinitialization/re-execution,
the optimizer reallocates JOIN::join_tab, JOIN::table in make_simple_join()
and the local variable in 'sortorder' in create_sort_index(), which is
allocated by make_unireg_sortorder().
Care must be taken not to allocate anything into the thread's memory pool
while re-initializing query plan structures between subquery re-executions.
All such items mush be cached and reused because the thread's memory pool
is freed at the end of the whole query.
Note that they must be cached and reused even for queries that are not
otherwise cacheable because otherwise it will grow the thread's memory
pool every time a cacheable query is re-executed.
We provide additional members to the JOIN structure to store references
to the items that need to be cached.
account predicates that become sargable after reading const tables.
In some cases this resulted in choosing non-optimal execution plans.
Now info of such potentially saragable predicates is saved in
an array and after reading const tables we check whether this
predicates has become saragable.
mysql-test/r/select.result:
Added a test case for bug #19579.
mysql-test/t/select.test:
Added a test case for bug #19579.
sql/item_cmpfunc.cc:
Fixed bug #19579: at range analysis optimizer did not take into
account predicates that become sargable after reading const tables.
Added a counter of between predicates.
sql/sql_base.cc:
Fixed bug #19579: at range analysis optimizer did not take into
account predicates that become sargable after reading const tables.
Added a counter of between predicates.
sql/sql_lex.cc:
Fixed bug #19579: at range analysis optimizer did not take into
account predicates that become sargable after reading const tables.
Added a counter of between predicates.
sql/sql_lex.h:
Fixed bug #19579: at range analysis optimizer did not take into
account predicates that become sargable after reading const tables.
Added a counter of between predicates.
sql/sql_select.cc:
Fixed bug #19579: at range analysis optimizer did not take into
account predicates that become sargable after reading const tables.
Now info of such potentially saragable predicates is saved in
an array and after reading const tables we check whether this
predicates has become saragable.
account predicates that become sargable after reading const tables.
In some cases this resulted in choosing non-optimal execution plans.
Now info of such potentially saragable predicates is saved in
an array and after reading const tables we check whether this
predicates has become saragable.
into willster.(none):/home/stewart/Documents/MySQL/5.0/bug19914-mk2-merge
sql/ha_berkeley.cc:
Auto merged
sql/ha_berkeley.h:
Auto merged
BitKeeper/deleted/.del-ha_isam.cc~4dce65904db2675e:
Auto merged
BitKeeper/deleted/.del-ha_isam.h~bf53d533be3d3927:
Auto merged
BitKeeper/deleted/.del-ha_isammrg.cc~dc682e4755d77a2e:
Auto merged
BitKeeper/deleted/.del-ha_isammrg.h~66fd2e5bfe7207dc:
Auto merged
sql/ha_archive.cc:
Auto merged
sql/ha_archive.h:
Auto merged
sql/ha_blackhole.cc:
Auto merged
sql/ha_blackhole.h:
Auto merged
sql/ha_heap.cc:
Auto merged
sql/ha_heap.h:
Auto merged
sql/ha_innodb.cc:
Auto merged
sql/ha_innodb.h:
Auto merged
sql/ha_myisam.cc:
Auto merged
sql/ha_myisam.h:
Auto merged
sql/ha_myisammrg.cc:
Auto merged
sql/ha_myisammrg.h:
Auto merged
sql/item_sum.cc:
Auto merged
sql/opt_sum.cc:
Auto merged
sql/sql_delete.cc:
Auto merged
sql/examples/ha_example.cc:
Auto merged
sql/examples/ha_example.h:
Auto merged
sql/examples/ha_tina.cc:
Auto merged
sql/examples/ha_tina.h:
Auto merged
sql/sql_union.cc:
Auto merged
sql/ha_ndbcluster.cc:
merge
sql/ha_ndbcluster.h:
merge
sql/handler.h:
merge
sql/sql_select.cc:
merge
into janus.mylan:/usr/home/serg/Abk/mysql-maria
configure.in:
Auto merged
include/my_global.h:
Auto merged
include/my_sys.h:
Auto merged
mysys/Makefile.am:
Auto merged
sql/item_func.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/mysqld.cc:
Auto merged
sql/set_var.cc:
Auto merged
sql/sql_parse.cc:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_test.cc:
Auto merged
storage/maria/Makefile.am:
Auto merged
storage/maria/ha_maria.cc:
Auto merged
storage/myisam/ha_myisam.cc:
Auto merged
unittest/Makefile.am:
Auto merged
unittest/mysys/my_atomic-t.c:
merged
Examined rows are counted for every join part. The per-join-part
counter was incremented over all iterations. The result variable
was replaced at the end of every iteration. The final result was
the number of examined rows by the join part that ended its
execution as the last one. The numbers of other join parts was
lost.
Now we reset the per-join-part counter before every iteration and
add it to the result variable at the end of the iteration. That
way we get the sum of all iterations of all join parts.
No test case. Testing this needs a look into the slow query log.
I don't know of a way to do this portably with the test suite.
sql/sql_select.cc:
Bug#12240 - Rows Examined in Slow Log showing incorrect number?
Fixed reseting and accumulation of examined rows counts.
Examined rows are counted for every join part. The per-join-part
counter was incremented over all iterations. The result variable
was replaced at the end of every iteration. The final result was
the number of examined rows by the join part that ended its
execution as the last one. The numbers of other join parts was
lost.
Now we reset the per-join-part counter before every iteration and
add it to the result variable at the end of the iteration. That
way we get the sum of all iterations of all join parts.
No test case. Testing this needs a look into the slow query log.
I don't know of a way to do this portably with the test suite.
Currently SQL_BIG_RESULT is checked only at compile time.
However, additional optimizations may take place after
this check that change the sort method from 'filesort'
to sorting via index. As a result the actual plan
executed is not the one specified by the SQL_BIG_RESULT
hint. Similarly, there is no such test when executing
EXPLAIN, resulting in incorrect output.
The patch corrects the problem by testing for
SQL_BIG_RESULT both during the explain and execution
phases.
mysql-test/r/bdb.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/r/group_by.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with MyISAM
mysql-test/r/innodb.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/r/innodb_mysql.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with InnoDB
mysql-test/r/myisam.result:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- updated sql_big_result testcase
mysql-test/t/group_by.test:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with MyISAM
mysql-test/t/innodb_mysql.test:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- test case with InnoDB
sql/sql_select.cc:
Bug #22781: SQL_BIG_RESULT fails to influence sort plan
- When SQL_BIG_RESULT is specified, disable the optimization performed
at execution/explain time that decides to use an index instead
of filesort.
Currently SQL_BIG_RESULT is checked only at compile time.
However, additional optimizations may take place after
this check that change the sort method from 'filesort'
to sorting via index. As a result the actual plan
executed is not the one specified by the SQL_BIG_RESULT
hint. Similarly, there is no such test when executing
EXPLAIN, resulting in incorrect output.
The patch corrects the problem by testing for
SQL_BIG_RESULT both during the explain and execution
phases.
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
procedures. However, 4.1 had some bugs that were fixed in 5.0 by the
patch for bug#21726, and this patch is a backport of those fixes.
Namely, in 4.1 it fixes:
- LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
- LAST_INSERT_ID() could return the value generated by current
statement if the call happens after the generation, like in
CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
- Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
mysql-test/r/rpl_insert_id.result:
Add result for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID.
mysql-test/t/rpl_insert_id.test:
Add test case for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID.
sql/item_func.cc:
Add implementation of Item_func_last_insert_id::fix_fields(), where we
set THD::last_insert_id_used when statement calls LAST_INSERT_ID().
In Item_func_last_insert_id::val_int(), return THD::current_insert_id
if called like LAST_INSERT_ID(), otherwise return value of argument if
called like LAST_INSERT_ID(expr).
sql/item_func.h:
Add declaration of Item_func_last_insert_id::fix_fields().
sql/log_event.cc:
Do not set THD::last_insert_id_used on LAST_INSERT_ID_EVENT. Though we
know the statement will call LAST_INSERT_ID(), it wasn't called yet.
sql/set_var.cc:
In sys_var_last_insert_id::value_ptr(), set THD::last_insert_id_used,
and return THD::current_insert_id for @@LAST_INSERT_ID.
sql/sql_class.h:
Update comments.
Remove THD::insert_id(), as it has lost its purpose now.
sql/sql_insert.cc:
Now it is OK to read THD::last_insert_id directly.
sql/sql_load.cc:
Now it is OK to read THD::last_insert_id directly.
sql/sql_parse.cc:
In mysql_execute_command(), remember THD::last_insert_id (first
generated value of the previous statement) in THD::current_insert_id,
which then will be returned for LAST_INSERT_ID() and @@LAST_INSERT_ID.
sql/sql_select.cc:
If "IS NULL" is replaced with "= <LAST_INSERT_ID>", use right value,
which is THD::current_insert_id, and also set THD::last_insert_id_used
to issue binary log LAST_INSERT_ID_EVENT.
sql/sql_update.cc:
Now it is OK to read THD::last_insert_id directly.
tests/mysql_client_test.c:
Add test case for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID.
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
procedures. However, 4.1 had some bugs that were fixed in 5.0 by the
patch for bug#21726, and this patch is a backport of those fixes.
Namely, in 4.1 it fixes:
- LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
- LAST_INSERT_ID() could return the value generated by current
statement if the call happens after the generation, like in
CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
- Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
invocations of LAST_INSERT_ID.
Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
and no LAST_INSERT_ID_EVENT was issued for binary log.
The solution is to add THD::last_insert_id_used_bin_log, which is much
like THD::last_insert_id_used, but is reset only for upper-level
statements. This new variable is used to issue LAST_INSERT_ID_EVENT.
mysql-test/r/rpl_insert_id.result:
For bug#21726, add result for statement-based replication of function
calls.
mysql-test/t/rpl_insert_id.test:
For bug#21726, add test case for statement-based replication of function
calls.
sql/item_func.cc:
Set THD::last_insert_id_used_bin_log for issuing of LAST_INSERT_ID_EVENT.
sql/log.cc:
Issue LAST_INSERT_ID_EVENT if THD::last_insert_id_used_bin_log is set.
sql/set_var.cc:
Set THD::last_insert_id_used_bin_log for issuing of LAST_INSERT_ID_EVENT.
sql/sql_class.cc:
Initialize THD::last_insert_id_used_bin_log.
Fix typo, add whitespace.
sql/sql_class.h:
Add THD::last_insert_id_used_bin_log.
sql/sql_parse.cc:
Reset THD::last_insert_id_used_bin_log for upper-level statements.
sql/sql_select.cc:
Set THD::last_insert_id_used_bin_log for issuing of LAST_INSERT_ID_EVENT.
invocations of LAST_INSERT_ID.
Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
and no LAST_INSERT_ID_EVENT was issued for binary log.
The solution is to add THD::last_insert_id_used_bin_log, which is much
like THD::last_insert_id_used, but is reset only for upper-level
statements. This new variable is used to issue LAST_INSERT_ID_EVENT.
into mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
mysql-test/r/ps.result:
Auto merged
mysql-test/t/ps.test:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/sql_select.cc:
Auto merged
sql/sql_update.cc:
Auto merged
into mockturtle.local:/home/dlenev/src/mysql-5.1-rt-merge
mysql-test/r/ps.result:
Auto merged
mysql-test/t/ps.test:
Auto merged
sql/item.cc:
Auto merged
sql/mysql_priv.h:
Auto merged
sql/opt_range.cc:
Auto merged
sql/sql_select.cc:
Auto merged
Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.
The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).
The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.
Version 5.1 does not have this bug (it was fixed by WL 3146).
mysql-test/r/rpl_insert_id.result:
Add results for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID, and bug#20339: stored procedure using LAST_INSERT_ID()
does not replicate statement-based.
mysql-test/t/rpl_insert_id.test:
Add test cases for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID, and bug#20339: stored procedure using LAST_INSERT_ID()
does not replicate statement-based.
sql/item_func.cc:
Add implementation of Item_func_last_insert_id::fix_fields(), where we
remember in THD::current_insert_id the first value generated during
execution of the previous statement, which is returned then from
Item_func_last_insert_id::val_int().
sql/item_func.h:
Add declaration of Item_func_last_insert_id::fix_fields().
sql/log_event.cc:
Do not set THD::last_insert_id_used on LAST_INSERT_ID_EVENT. Though we
know the statement will call LAST_INSERT_ID(), it wasn't called yet.
sql/set_var.cc:
In sys_var_last_insert_id::value_ptr() remember in
THD::current_insert_id the first value generated during execution of the
previous statement, and return this value for @@LAST_INSERT_ID.
sql/sql_class.cc:
Reset THD::last_insert_id_used after each statement execution.
sql/sql_class.h:
Rather then remember current insert_id value on first invocation of
THD::insert_id(), remember it in Item_func_last_insert_id::fix_fields(),
sys_var_last_insert_id::value_ptr(), or mysql_execute_command().
Remove THD::insert_id(), as it lost its value now.
sql/sql_insert.cc:
THD::insert_id() is removed, use THD::last_insert_id directly.
sql/sql_load.cc:
THD::insert_id() is removed, using THD::last_insert_id directly is OK.
sql/sql_parse.cc:
Remember in THD::current_insert_id first generated insert id value of
the previous statement in mysql_execute_command().
No need to reset THD::last_insert_id_used in
mysql_reset_thd_for_next_command(), it will be reset after each
statement.
sql/sql_select.cc:
If "IS NULL" is replaced with "= <LAST_INSERT_ID>", use right value,
which is THD::current_insert_id, and also set THD::last_insert_id_used
to issue binary log LAST_INSERT_ID_EVENT.
sql/sql_update.cc:
THD::insert_id() is removed, use THD::last_insert_id directly.
tests/mysql_client_test.c:
Add test case for bug#21726: Incorrect result with multiple invocations
of LAST_INSERT_ID.
Non-upper-level INSERTs (the ones in the body of stored procedure,
stored function, or trigger) into a table that have AUTO_INCREMENT
column didn't affected the result of LAST_INSERT_ID() on this level.
The problem was introduced with the fix of bug 6880, which in turn was
introduced with the fix of bug 3117, where current insert_id value was
remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
returned from that function until it was reset before the next
_upper-level_ statement (bug 6880).
The fix for bug#21726 brings back the behaviour of version 4.0, and
implements the following: remember insert_id value at the beginning
of the statement or expression (which at that point equals to
the first insert_id value generated by the previous statement), and
return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
Thus, the value returned by LAST_INSERT_ID() is not affected by values
generated by current statement, nor by LAST_INSERT_ID(expr) calls in
this statement.
Version 5.1 does not have this bug (it was fixed by WL 3146).
Fix for bug 7894 replaces a field(s) in a non-aggregate function with a item
reference if such a field was specified in the GROUP BY clause in order to
get a correct result.
When ROLLUP is involved this lead to a wrong result due to value of a such
field is got through a copy function and copying happens after the function
evaluation.
Such replacement isn't needed if grouping is also done by such a function.
The change_group_ref() function now isn't called for a function present in
the group list.
mysql-test/t/olap.test:
Added the test case for the bug#20825: rollup puts non-equal values together
mysql-test/r/olap.result:
Added the test case for the bug#20825: rollup puts non-equal values together
sql/sql_select.cc:
Fixed bug#20825: rollup puts non-equal values together
The change_group_ref() function now isn't called for a function present in
the group list.
Fix for bug 7894 replaces a field(s) in a non-aggregate function with a item
reference if such a field was specified in the GROUP BY clause in order to
get a correct result.
When ROLLUP is involved this lead to a wrong result due to value of a such
field is got through a copy function and copying happens after the function
evaluation.
Such replacement isn't needed if grouping is also done by such a function.
The change_group_ref() function now isn't called for a function present in
the group list.
- Re-worked the prev_record_reads() function to return the lower bound of
number of different table access scans that will be performed.
mysql-test/r/join.result:
BUG#14940: testcase
mysql-test/t/join.test:
BUG#14940: testcase
sql/sql_select.cc:
BUG#14940: Slow join order is chosen:
- Re-worked the prev_record_reads() function to return the lower bound of
number of different table access scans that will be performed.
sql/sql_select.h:
BUG#14940: Slow join order is chosen:
- Added comments in struct POSITION
- Added POSITION::ref_depend_map: bitmap of tables that the table access
method depends on.
