mariadb

Commit Graph

Author	SHA1	Message	Date
Sergei Golubchik	a058974440	remove HAVE_EXPLICIT_TEMPLATE_INSTANTIATION	13 years ago
Igor Babaev	a06224bd15	Addressed all remaining issues from the review of the patch that introduced engine independent persistent statistics. In particular: - added an enumeration type for possible values of the system variable use_stat_tables - renamed KEY::real_rec_per_key to KEY::actual_rec_per_key - optimized the collection of statistical data for any primary key defined only on one column.	13 years ago
unknown	1b2692d0e9	MDEV-3899 Valgrind warnings (blocks are definitely lost) in filesort on IN subquery with SUM and DISTINCT Analysys: In the beginning of JOIN::cleanup there is code that is supposed to free all filesort buffers. The code assumes that the table being sorted is the first non-constant table. To get this table it calls: first_top_level_tab(this, WITHOUT_CONST_TABLES) However, first_top_level_tab() instead returned the wrong table - the first one in the plan, instead of the first non-constant table. There is no other place outside filesort() where sort buffers may be freed. As a result, the sort buffer was not freed, and there was a memory leak. Solution: Change first_top_level_tab(), to test for WITH_CONST_TABLES instead of WITHOUT_CONST_TABLES.	13 years ago
unknown	b8b875cb79	Fix of MDEV-3874: Server crashes in Item_field::print on a SELECT from a MERGE view with materialization+semijoin, subquery, ORDER BY. The problem was that in debugging binaries it try to print item to assign human readable name to the item. But subquery item was already freed (join_free/cleanup with full cleanup) so Item_field refers to temporary table which memory had been already freed.	13 years ago
unknown	60a7b05871	MDEV-3801 Reproducible sub select join crash on 5.3.8 and 5.3.9 Properly drop all unused keys. Patch by Igor Babaev.	13 years ago
Igor Babaev	4d44261052	Fixed bug mdev-622 (LP bug #1002508 ). Back-ported the fix and the test case for bug 13528826 from mysql-5.6.	13 years ago
Igor Babaev	e08f4f1630	Fixed bug mdev-3851. Any ref access to a table by a key fully extended by the components of the primary key should be actually an eq_ref access.	13 years ago
Sergey Petrunya	39e7072d64	MDEV-536: LP:1050806 - different result for a query using subquery, and MDEV-567: Wrong result from a query with correlated subquery if ICP is allowed: backport the fix developed for SHOW EXPLAIN: revision-id: psergey@askmonty.org-20120719115219-212cxmm6qvf0wlrb branch nick: 5.5-show-explain-r21 timestamp: Thu 2012-07-19 15:52:19 +0400 BUG#992942 & MDEV-325: Pre-liminary commit for testing and adjust it so that it handles DS-MRR scans correctly.	13 years ago
Igor Babaev	7714739b2d	Fixed bug mdev-585 (LP bug #637962 ) If, when executing a query with ORDER BY col LIMIT n, the optimizer chose an index-merge scan to access the table containing col while there existed an index defined over col then optimizer did not consider the possibility of using an alternative range scan by this index to avoid filesort. This could cause a performance degradation if the optimizer flag index_merge was set up to 'on'.	13 years ago
unknown	bc4a456758	MDEV-452 Add full support for auto-initialized/updated timestamp and datetime Generalized support for auto-updated and/or auto-initialized timestamp and datetime columns. This patch is a reimplementation of MySQL's "WL#5874: CURRENT_TIMESTAMP as DEFAULT for DATETIME columns". In order to ease future merges, this implementation reused few function and variable names from MySQL's patch, however the implementation is quite different. TODO: The only unresolved problem in this patch is the semantics of LOAD DATA for TIMESTAMP and DATETIME columns in the cases when there are missing or NULL columns. I couldn't fully comprehend the logic behind MySQL's behavior and its relationship with their own documentation, so I left the results to be more consistent with all other LOAD cases. The problematic test cases can be seen by running the test file function_defaults, and observing the test case differences. Those were left on purpose for discussion.	13 years ago
unknown	e47cdfdfb6	MDEV-435: Expensive subqueries may be evaluated during optimization in merge_key_fields Fix by Sergey Petrunia. This patch only prevents the evaluation of expensive subqueries during optimization. The crash reported in this bug has been fixed by some other patch. The fix is to call value->is_null() only when !value->is_expensive(), because is_null() may trigger evaluation of the Item, which in turn triggers subquery evaluation if the Item is a subquery.	13 years ago
unknown	8215ce4695	MDEV-3804: MySQL fix for bug#11765413 removed (we have better and more general fix for the problem). Test suite added.	13 years ago
Sergey Petrunya	d2d6c8b8e8	Backport of: olav.sandstaa@oracle.com-20120516074923-vd0dhp183vqcp2ql .. into MariaDB 5.3 Fix for Bug#12667154 SAME QUERY EXEC AS WHERE SUBQ GIVES DIFFERENT RESULTS ON IN() & NOT IN() COMP #3 This bug causes a wrong result in mysql-trunk when ICP is used and bad performance in mysql-5.5 and mysql-trunk. Using the query from bug report to explain what happens and causes the wrong result from the query when ICP is enabled: 1. The t3 table contains four records. The outer query will read these and for each of these it will execute the subquery. 2. Before the first execution of the subquery it will be optimized. In this case the important is what happens to the first table t1: -make_join_select() will call the range optimizer which decides that t1 should be accessed using a range scan on the k1 index It creates a QUICK_RANGE_SELECT object for this. -As the last part of optimization the ICP code pushes the condition down to the storage engine for table t1 on the k1 index. This produces the following information in the explain for this table: 2 DEPENDENT SUBQUERY t1 range k1 k1 5 NULL 3 Using index condition; Using filesort Note the use of filesort. 3. The first execution of the subquery does (among other things) due to the need for sorting: a. Call create_sort_index() which again will call find_all_keys(): b. find_all_keys() will read the required keys for all qualifying rows from the storage engine. To do this it checks if it has a quick-select for the table. It will use the quick-select for reading records. In this case it will read four records from the storage engine (based on the range criteria). The storage engine will evaluate the pushed index condition for each record. c. At the end of create_sort_index() there is code that cleans up a lot of stuff on the join tab. One of the things that is cleaned is the select object. The result of this is that the quick-select object created in make_join_select is deleted. 4. The second execution of the subquery does the same as the first but the result is different: a. Call create_sort_index() which again will call find_all_keys() (same as for the first execution) b. find_all_keys() will read the keys from the storage engine. To do this it checks if it has a quick-select for the table. Now there is NO quick-select object(!) (since it was deleted in step 3c). So find_all_keys defaults to read the table using a table scan instead. So instead of reading the four relevant records in the range it reads the entire table (6 records). It then evaluates the table's condition (and here it goes wrong). Since the entire condition has been pushed down to the storage engine using ICP all 6 records qualify. (Note that the storage engine will not evaluate the pushed index condition in this case since it was pushed for the k1 index and now we do a table scan without any index being used). The result is that here we return six qualifying key values instead of four due to not evaluating the table's condition. c. As above. 5. The two last execution of the subquery will also produce wrong results for the same reason. Summary: The problem occurs due to all but the first executions of the subquery is done as a table scan without evaluating the table's condition (which is pushed to the storage engine on a different index). This is caused by the create_sort_index() function deleting the quick-select object that should have been used for executing the subquery as a range scan. Note that this bug in addition to causing wrong results also can result in bad performance due to executing the subquery using a table scan instead of a range scan. This is an issue in MySQL 5.5. The fix for this problem is to avoid that the Quick-select-object that the optimizer created is deleted when create_sort_index() is doing clean-up of the join-tab. This will ensure that the quick-select object and the corresponding pushed index condition will be available and used by all following executions of the subquery.	13 years ago
unknown	4304dbc464	MDEV-616 fix (MySQL fix accepted)	13 years ago
unknown	72ab07c1cb	MDEV-746: Merged mysql fix of the bug LP:1002546 & MySQL Bug#13651009. Empty result after reading const tables now works for subqueries.	13 years ago
Sergey Petrunya	850fb90177	Remove unneeded comments	13 years ago
Igor Babaev	a6b88f1431	MDEV-415: Back-port of the WL task #1393 from the mysql-5.6 code line. The task adds a more efficient handling of the queries with ORDER BY order LIMIT n, such that n is small enough and no indexes are used for order.	13 years ago
Sergei Golubchik	4a8938f6f5	remove the forgotten commented out piece of the old merge	13 years ago
Sergei Golubchik	a1fd37b1fd	MDEV-414 Depending on indexes or execution plans, a warning on incorrect or out of range values in WHERE condition is sometimes produced and sometimes not use the same method that disables warnings in all relevant places, remove redundant function	13 years ago
Sergey Petrunya	2d99ea454f	MDEV-430: Server crashes in select_describe on EXPLAIN with materialization+semijoin, etc - Don't do early cleanup of uncorrelated subqueries if we're running an EXPLAIN.	13 years ago
unknown	4d2b05b7d7	fix for MDEV-367 The problem was that was_null and null_value variables was reset in each reexecution of IN subquery, but engine rerun only for non-constant subqueries. Fixed checking constant in Item_equal sort. Fix constant reporting in Item_subselect.	13 years ago
Tor Didriksen	a16e00a6c4	Bug#14463247 ORDER BY SUBQUERY REFERENCING OUTER ALIAS FAILS Documentation for class Item_outer_ref was wrong: (ref) may point to Item_field as well (see e.g. Item_outer_ref::fix_fields) So this casting in get_store_key() was wrong: ((Item_ref*)((Item_ref)keyuse->val)->ref)->ref_type()	13 years ago
unknown	80b3f74705	Fix bug mdev-447: Wrong output from the EXPLAIN command of the test case for lp bug #714999 The fix backports from MWL#182: Explain running statements the logic that saves the original JOIN_TAB array of a query plan after optimization. This array is later used during EXPLAIN to iterate over the original JOIN plan nodes in the cases when this plan could be changed by early subquery execution during the optimization phase of the outer query.	13 years ago
Michael Widenius	dd8bd2e4c3	Fixed compiler warnings sql/item_subselect.cc: Added purecov info sql/sql_select.cc: Added cast storage/innobase/handler/ha_innodb.cc: Added cast storage/xtradb/btr/btr0btr.c: Added buf_block_get_frame_fast() to avoid compiler warning storage/xtradb/handler/ha_innodb.cc: Added cast storage/xtradb/include/buf0buf.h: Innodb has buf_block_get_frame(block) defined as (block)->frame. Didn't want to do a big change to break xtradb as it may use block_get_frame() differently, so I mad this quick hack to patch one compiler warning.	13 years ago
Michael Widenius	b886cac712	Fixed compiler errors Updated test to also work on 32 bit mysql-test/suite/heap/heap.test: Updated test to also work on 32 bit	13 years ago
Sergey Glukhov	2f30b34095	Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution. sql/item_subselect.cc: addon, fix for 11829691, item could be created in runtime memroot, so we need to use real_item instead.	13 years ago
Sergey Petrunya	59e64b6c9b	MDEV-416: Server crashes in SQL_SELECT::cleanup on EXPLAIN with SUM ( DISTINCT ) - When JOIN::cleanup(full==TRUE) is called, the select can be in two states: = Right after the create_sort_index() call, when join->join_tab[0] is used to read data produced by filesort(). = After create_sort_index(), and after JOIN::reinit() calls, when join->join_tab[0] has been reset to read the original data. - We didn't handle the second case correctly, which resulted in an attempt to free the same SQL_SELECT two times. The fix is to make sure we don't double-free.	14 years ago
Sergey Petrunya	fd3e9c53c1	MDEV-423: SHOW EXPLAIN: 'Using where' for a subquery is shown in EXPLAIN, but not in SHOW EXPLAIN - Take into account that the optimizer may run the subquery, delete it, and then make a JOIN::optimize call again.	14 years ago
Sergey Petrunya	aaa188dad9	Post-merge fixes.	14 years ago
Igor Babaev	8c499274da	Performed re-factoring and re-structuring of the code for mwl#248: - Moved the definitions of the classes to store data from persistent statistical tables into statistics.h, leaving in other internal data structures only references to the corresponding objects. - Defined class Column_statistics_collected derived from the class Column_statistics. This is a helper class to collect statistics on columns. - Moved references to read statistics to TABLE SHARE, leaving the the reference to the collected statistics in TABLE. - Added a new clone method for the class Field allowing to clone fields attached to table shares. It was was used to create fields for min/max values in the memory of the table share. A lso: - Added procedures to allocate memory for statistical data in the table share memory and in table memory. Also: - Added a test case demonstrating how ANALYZE could work in parallel to collect statistics on different indexes of the same table. - Added a test two demonstrate how two connections working simultaneously could allocate memory for statistical data in the table share memory.	14 years ago
Sergey Petrunya	0b79fe2b30	MDEV-412: SHOW EXPLAIN: Server crashes in JOIN::print_explain on a query with inner join and ORDER BY the same column twice - JOIN::print_explain should print pre_sort_join_tab instead of "first non-constant table". The code didn't take the "non-constant" part into account.	14 years ago
Sergey Petrunya	ab70b76d9c	BUG#992942 & MDEV-325: Pre-liminary commit for testing	14 years ago
Chaithra Gopalareddy	ddcd6867e9	Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH "ORDER BY" AND "LIMIT BY" CLAUSE PROBLEM: When a 'limit' clause is specified in a query along with group by and order by, optimizer chooses wrong index there by examining more number of rows than required. However without the 'limit' clause, optimizer chooses the right index. ANALYSIS: With respect to the query specified, range optimizer chooses the first index as there is a range present ( on 'a'). Optimizer then checks for an index which would give records in sorted order for the 'group by' clause. While checking chooses the second index (on 'c,b,a') based on the 'limit' specified and the selectivity of 'quick_condition_rows' (number of rows present in the range) in 'test_if_skip_sort_order' function. But, it fails to consider that an order by clause on a different column will result in scanning the entire index and hence the estimated number of rows calculated above are wrong (which results in choosing the second index). FIX: Do not enforce the 'limit' clause in the call to 'test_if_skip_sort_order' if we are creating a temporary table. Creation of temporary table indicates that there would be more post-processing and hence will need all the rows. This fix is backported from 5.6. This problem is fixed in 5.6 as part of changes for work log #5558 mysql-test/r/subselect.result: Changes for Bug#11762052 results in the correct number of rows. sql/sql_select.cc: Do not pass the actual 'limit' value if 'need_tmp' is true.	14 years ago
Michael Widenius	f27c26e95a	Fixed compiler warnings client/mysqltest.cc: Added cast plugin/feedback/utils.cc: Added #ifdef sql/sql_select.cc: Added cast sql/sys_vars.h: Changed limits to int support-files/compiler_warnings.supp: Added suppression	14 years ago
Sergey Petrunya	89820b4202	Better comments.	14 years ago
Sergey Petrunya	94bf016321	sql_select.cc: work compiler warnings my_apc-t.cc: make it compile on Windows.	14 years ago
Igor Babaev	4ff6fd34da	Changed the type of all double columns in the system statistical tables mysql.column_stat, mysql.table_stat for the type DECIMAL(12,4). When cached the values from these columns are multiplied by factor 10^5 and stored as ulong numbers now.	14 years ago
Sergey Petrunya	66c62de103	MWL#182: Explain running statements - Remove out-of-date comments, add dbug assertions.	14 years ago
Norvald H. Ryeng	cac1cd88ab	Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES Problem: Some queries with subqueries and a HAVING clause that consists only of a column not in the select or grouping lists causes the server to crash. During parsing, an Item_ref is constructed for the HAVING column. The name of the column is resolved when JOIN::prepare calls fix_fields() on its having clause. Since the column is not mentioned in the select or grouping lists, a ref pointer is not found and a new Item_field is created instead. The Item_ref is replaced by the Item_field in the tree of HAVING clauses. Since the tree consists only of this item, the pointer that is updated is JOIN::having. However, st_select_lex::having still points to the Item_ref as the root of the tree of HAVING clauses. The bug is triggered when doing filesort for create_sort_index(). When find_all_keys() calls select->cond->walk() it eventually reaches Item_subselect::walk() where it continues to walk the having clauses from lex->having. This means that it finds the Item_ref instead of the new Item_field, and Item_ref::walk() tries to dereference the ref pointer, which is still null. The crash is reproducible only in 5.5, but the problem lies latent in 5.1 and trunk as well. Fix: After calling fix_fields on the having clause in JOIN::prepare(), set select_lex::having to point to the same item as JOIN::having. This patch also fixes a bug in 5.1 and 5.5 that is triggered if the query is executed as a prepared statement. The Item_field is created in the runtime arena when the query is prepared, and the pointer to the item is saved by st_select_lex::fix_prepare_information() and brought back as a dangling pointer when the query is executed, after the runtime arena has been reclaimed. Fix: Backport fix from trunk that switches to the permanent arena before calling Item_ref::fix_fields() in JOIN::prepare(). sql/item.cc: Set context when creating Item_field. sql/sql_select.cc: Switch to permanent arena and update select_lex->having.	14 years ago
Sergey Petrunya	cf8461a0f7	SHOW EXPLAIN: Code cleanup	14 years ago
Sergey Petrunya	5eecea8caf	MDEV-324: SHOW EXPLAIN: Plan produced by SHOW EXPLAIN for a query with TEMPTABLE view loses 'DERIVED' line - Make SHOW EXPLAIN code take into account that st_select_lex object without joins can be a full-featured SELECTs which were already executed and cleaned up.	14 years ago
Michael Widenius	56ea8e9c05	Fixed build failures found by buildbot - Added suppression of warnings - Fixed some test cases BUILD/FINISH.sh: Added AM_EXTRA_MAKEFLAGS BUILD/SETUP.sh: Added option --extra-makeflags client/mysqldump.c: Added suppression mysql-test/r/mysql.result: Updated results mysql-test/r/mysql_upgrade.result: Updated results mysql-test/r/partition_innodb_plugin.result: Updated results mysql-test/r/partition_open_files_limit.result: Updated results mysql-test/r/symlink.result: Updated results mysql-test/suite/innodb/r/innodb-create-options.result: Updated results mysql-test/suite/innodb/t/innodb-create-options.test: Don't print error message (as it's varies on different system) mysql-test/t/mysql.test: Don't print error message (as it's varies on different system) mysql-test/t/mysql_upgrade.test: Fixed checking of error number mysql-test/t/partition_innodb_plugin.test: Don't print error message (as it's varies on different system) plugin/semisync/semisync_master.cc: Added suppression sql/ha_partition.cc: Added suppression sql/item_subselect.cc: Added suppression sql/multi_range_read.cc: Added suppression sql/sql_parse.cc: Added suppression sql/sql_select.cc: Added suppression storage/innobase/handler/ha_innodb.cc: Removed not used variable storage/maria/ma_delete.c: Added suppression storage/maria/ma_key_recover.c: Added suppression storage/maria/ma_write.c: Added suppression strings/ctype-ucs2.c: Added suppression support-files/compiler_warnings.supp: Added suppressions unittest/mysys/my_vsnprintf-t.c: Fixed test case with %M to also work on Solaris	14 years ago
Sergey Petrunya	9a7b3bf4b7	MDEV-299: SHOW EXPLAIN: Plan produced by SHOW EXPLAIN changes back and forth during query execution - Make SHOW EXPLAIN ignore range accesses when printing "Range checked for each record" plans.	14 years ago
Sergey Petrunya	13e985787e	Added comments about create_ref_for_key()	14 years ago
Sergey Petrunya	a8b2e831f0	MDEV-305: SHOW EXPLAIN: ref returned by SHOW EXPLAIN is different from the normal EXPLAIN ('const' vs empty string) - The problem was that create_ref_for_key() would act differently, depending on whether we're running EXPLAIN or the actual query. - As the first step, fixed the EXPLAIN printout not to depend on actions in create_ref_for_key().	14 years ago
unknown	7ddd5418d0	Fixed bug MDEV-288 CHEAP SQ: Valgrind warnings "Memory lost" with IN and EXISTS nested subquery, materialization+semijoin Analysis: The memory leak was a result of the interaction of semi-join optimization with early optimization of constant subqueries. The function: setup_jtbm_semi_joins() created a dummy temporary table "dummy_table" in order to make some JOIN_TAB objects complete. Normally, such temporary tables are freed inside JOIN_TAB::cleanup. However, the inner-most subquery is pre-optimized, which allows the optimization fo the MAX subquery to determine that its WHERE is TRUE, and thus to compute the result of the MAX during optimization. This ultimately allows the optimize phase of the outer query to find that it WHERE clause is FALSE. Once JOIN::optimize finds that the result set is empty, it sets zero_result_cause, and returns before it ever reached make_join_statistics(). As a result the query plan has no JOIN_TABs at all. Since the temporary table is supposed to be cleanup via JOIN_TAB::cleanup, this never happens because there is no JOIN_TAB for this table. Hence we get a memory leak. Solution: Whenever there are no JOIN_TABs, iterate over all table reference in JOIN::join_list, and free the ones that contain semi-join temporary tables.	14 years ago
Annamalai Gurusami	a28a2ca798	Bug #13933132 : [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED WHEN KILLING Suppose there is a query waiting for a lock. If the user kills this query, then "Got error -1 when reading table" error message must not be logged in the server log file. Since this is a user requested interruption, no spurious error message must be logged in the server log. This patch will remove the error message from the log. approved by joh and tatjana	14 years ago
Annamalai Gurusami	a2bc9b3669	Bug #13933132 : [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED WHEN KILLING Suppose there is a query waiting for a lock. If the user kills this query, then "Got error -1 when reading table" error message must not be logged in the server log file. Since this is a user requested interruption, no spurious error message must be logged in the server log. This patch will remove the error message from the log. approved by joh and tatjana	14 years ago
Sergey Petrunya	5b73a17b3a	BUG#1002630: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SELECT - In JOIN::exec(), make the having->update_used_tables() call before we've made the JOIN::cleanup(full=true) call. The latter frees SJ-Materialization structures, which correlated subquery predicate items attempt to walk afterwards.	14 years ago
Sergey Petrunya	6f199f7c4f	MDEV-275: SHOW EXPLAIN: server crashes in JOIN::print_explain with IN subquery and aggregate function - Don't try to produce plans after JOIN::cleanup() has been called, because: = JOIN::cleanup leaves data structures in partially-cleaned state = Walking them is hazardous (see this bug), and has funny effects (See previous commits, "Using join cache" may or may not be shown) = Changing data structures to be persisted may cause unwanted side effects - The consequence is that SHOW EXPLAIN will show "Query plan already deleted" when e.g. reading data after filesort.	14 years ago

1 2 3 4 5 ...

3530 Commits (f853333e09b222f6d6d76d9343b6202b4769ffab)