Commit graph

11301 commits

Author SHA1 Message Date
unknown
7ac3645abd Merge bk-internal.mysql.com:/home/bk/mysql-5.0
into  bodhi.(none):/opt/local/work/mysql-5.0-runtime


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
sql/sql_parse.cc:
  Auto merged
2007-10-08 02:05:55 +04:00
unknown
4f14c13a1c Fix for BUG#31035: select from function, group by result crasher.
This actually, fix for the patch for bug-27354. The problem with
the patch was that Item_func_sp::used_tables() was updated, but
Item_func_sp::const_item() was not. So, for Item_func_sp, we had
the following inconsistency:
  - used_tables() returned RAND_TABLE, which means that the item
    can produce "random" results;
  - but const_item() returned TRUE, which means that the item is
    a constant one.

The fix is to change Item_func_sp::const_item() behaviour: it must
return TRUE (an item is a constant one) only if a stored function
is deterministic and each of its arguments (if any) is a constant
item.


mysql-test/r/sp.result:
  Update result file.
mysql-test/t/sp.test:
  Add test cases for BUG-31035, BUG-31191, BUG-31226
sql/item_func.cc:
  Make Item::const_item() be consistent with Item::used_tables().
2007-10-04 17:19:14 +04:00
unknown
ad57f91294 result fix 2007-09-20 14:38:41 +05:00
unknown
fac190a28b Bug#27747 database metadata doesn't return sufficient column default info
added get_field_default_value() function which obtains default value from the field
(used in store_create_info() & get_schema_column_record() functions)


mysql-test/r/alter_table.result:
  result fix
mysql-test/r/create.result:
  result fix
mysql-test/r/ctype_collate.result:
  result fix
mysql-test/r/ctype_recoding.result:
  result fix
mysql-test/r/default.result:
  result fix
mysql-test/r/gis.result:
  result fix
mysql-test/r/grant.result:
  result fix
mysql-test/r/information_schema.result:
  result fix
mysql-test/r/key.result:
  result fix
mysql-test/r/mysql.result:
  result fix
mysql-test/r/ps_1general.result:
  result fix
mysql-test/r/show_check.result:
  result fix
mysql-test/r/sp.result:
  result fix
mysql-test/r/type_enum.result:
  result fix
mysql-test/r/type_ranges.result:
  result fix
mysql-test/t/information_schema.test:
  test case
2007-09-20 13:54:46 +05:00
unknown
ffdc5b9302 Merge mysql.com:/home/gluh/MySQL/Merge/5.0
into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
2007-09-19 13:50:38 +05:00
unknown
f58cbe3d84 Merge gshchepa@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  devsrv-b.mysql.com:/data0/gshchepa/mysql-5.0-opt
2007-09-14 21:15:43 +02:00
unknown
4d8ec62d1a Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/autopush/B31001-5.0-opt
2007-09-14 19:04:47 +03:00
unknown
ad496be063 Bug #31001: ORDER BY DESC in InnoDB not working
The optimizer sets index traversal in reverse order only if there are 
 used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if 
all the parts of the secondary key are compared to a constant.

Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.


mysql-test/r/innodb_mysql.result:
  Bug #31001: test case
mysql-test/t/innodb_mysql.test:
  Bug #31001: test case
sql/sql_select.cc:
  Bug #31001: 
   - account for the case when all the primary key parts are compared
     to a constant
   - force test_if_skip_sort_order to go backwards over the key even 
     when the number of keyparts used is the same as the number of 
     keyparts equal to a constant. (because of the primary key 
     suffix).
2007-09-14 17:43:14 +03:00
unknown
2ab4e3d117 Merge spetrunia@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  mysql.com:/home/psergey/mysql-5.0-bug30324
2007-09-14 15:00:10 +04:00
unknown
466747d570 BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
- The bug was caused by COUNT(DISTINCT ...) code using Unique object in 
  a way that assumed that BIT(N) column occupies a contiguous space in
  temp_table->record[0] buffer. 
- The fix is to make COUNT(DISTINCT ...) code instruct create_tmp_table to
  create temporary table with column of type BIGINT, not BIT(N).


mysql-test/r/type_bit.result:
  BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
  - Testcase
mysql-test/t/type_bit.test:
  BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
  - Testcase
sql/item_sum.cc:
  BUG#30324: Grouping queries with COUNT(DISTINCT bit column) return wrong results
  - Make COUNT(DISTINCT ...) code instruct create_tmp_table to create 
    temporary table with BIGINT, not BIT(N) column.
2007-09-14 14:53:13 +04:00
unknown
820a2b8c51 Merge whalegate.ndb.mysql.com:/home/tomas/mysql-5.0
into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge
2007-09-14 11:08:55 +02:00
unknown
b9f9aa65b5 Merge gshchepa@bk-internal.mysql.com:/users/gshchepa/mysql-5.0-opt
into  gleb.loc:/home/uchum/work/bk/5.0-opt-27695
2007-09-14 13:11:50 +05:00
unknown
037a0f7677 Fixed bug #27695.
Declaring an all space column name in the SELECT FROM DUAL or in a view
leads to misleading warning message:
"Leading spaces are removed from name ' '".

The Item::set_name method has been modified to raise warnings like
"Name ' ' has become ''" in case of the truncation of an all
space identifier to an empty string identifier instead of the
"Leading spaces are removed from name ' '" warning message.


sql/item.cc:
  Fixed bug #27695.
  The Item::set_name method has been modified to raise warnings like
  "Name ' ' has become ''" in case of the truncation of an all
  space identifier to an empty string identifier instead of the
  "Leading spaces are removed from name ' '" warning message.
sql/share/errmsg.txt:
  Fixed bug #27695.
mysql-test/t/select.test:
  Added test case for bug #27695.
mysql-test/r/select.result:
  Added test case for bug #27695.
2007-09-13 18:41:50 +05:00
unknown
2978fcc3e9 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt


sql/sql_yacc.yy:
  Auto merged
mysql-test/r/sp.result:
  SCCS merged
mysql-test/t/sp.test:
  SCCS merged
2007-09-12 23:41:35 +05:00
unknown
345891d76b Merge whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge


mysql-test/Makefile.am:
  Auto merged
sql/ha_ndbcluster.cc:
  Auto merged
2007-09-12 14:01:51 +02:00
unknown
5f183053df Merge whalegate.ndb.mysql.com:/home/tomas/mysql-5.0
into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb-merge


sql/ha_ndbcluster.cc:
  Auto merged
2007-09-12 07:34:42 +02:00
unknown
ba39449e01 Post-merge fixes 2007-09-12 01:52:27 +04:00
unknown
9d466ad479 Merge mysql.com:/home/psergey/mysql-4.1-bug30385
into  mysql.com:/home/psergey/mysql-5.0-bug30385


sql/opt_range.cc:
  Auto merged
mysql-test/r/delete.result:
  Manual merge
mysql-test/t/delete.test:
  Manual merge
2007-09-11 02:24:08 +04:00
unknown
732f05a642 BUG#30385: Server crash when deleting with ORDER BY and LIMIT
in get_index_for_order(), don't walk over the end of the index key parts
when matching index description and needed ordering.


mysql-test/r/delete.result:
  BUG#30385: Testcase
mysql-test/t/delete.test:
  BUG#30385: Testcase
2007-09-10 16:26:51 +04:00
unknown
76e37a32b8 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
2007-09-06 22:27:13 +05:00
unknown
3a94137ce0 Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge


mysql-test/r/sp.result:
  Auto merged
mysql-test/t/mysql.test:
  Auto merged
mysql-test/t/sp.test:
  Auto merged
2007-09-04 14:38:26 -06:00
unknown
403ed43b1d Merge mhansson@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  dl145s.mysql.com:/data0/mhansson/my50-bug30234-push


sql/sql_yacc.yy:
  Auto merged
2007-09-03 12:44:17 +02:00
unknown
f0d4beee79 Bug #30234: Unexpected behavior using DELETE with AS and USING
DELETE FROM ... USING ... statements with the following type of 
ambiguous aliasing gave unexpected results:
DELETE FROM t1 AS alias USING t1, t2 AS alias WHERE t1.a = alias.a;
This query would leave table t1 intact but delete rows from t2.
Fixed by changing DELETE FROM ... USING syntax so that only alias 
references (as opposed to alias declarations) may be used in FROM.


mysql-test/r/delete.result:
  Bug#30234: Test Result
mysql-test/t/delete.test:
  Bug#30234: Test Case
sql/sql_yacc.yy:
  Bug#30234:
  - Added parser rule table_alias_ref_list that contains a list of table 
    aliases only.
  - Added parser rule table_alias_ref that sets the TL_OPTION_ALIAS in 
    order to turn off semantic checking that applies only for table names.
2007-09-03 11:55:35 +02:00
unknown
ee0b7d895d Bug#29408 Cannot find view in columns table if the selection contains a function
Use view db name as thread default database, in order to ensure
that the view is parsed and prepared correctly.


mysql-test/r/sp.result:
  test result
mysql-test/t/sp.test:
  test case
sql/sql_parse.cc:
  copy thd->db_length to table_list->db_length
sql/sql_view.cc:
  Use view db name as thread default database, in order to ensure
  that the view is parsed and prepared correctly.
2007-09-03 12:22:56 +05:00
unknown
b25b8cbc72 Merge gleb.loc:/home/uchum/work/bk/5.0-opt-30126
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-08-31 17:05:37 +05:00
unknown
ff149b713c Fixed bug #30126.
When dumping database from a 4.x server, the mysqldump client
inserted a delimiter sign inside special commentaries of the form:
  /*!... CREATE DATABASE IF NOT EXISTS ... ;*/
During restoration that dump file was splitten by delimiter signs on
the client side, and the rest of some commentary strings was prepended
to following statements.

The 4x_server_emul test case option has been added for use with the
DBUG_EXECUTE_IF debugging macro. This option affects debug server
builds only to emulate particular behavior of a 4.x server for
the mysqldump client testing. Non-debugging builds are not affected.


mysql-test/r/mysqldump-compat.result:
  Added test case for bug #30126.
mysql-test/t/mysqldump-compat.opt:
  Added test case for bug #30126.
mysql-test/t/mysqldump-compat.test:
  Added test case for bug #30126.
sql/sql_parse.cc:
  Fixed bug #30126.
  The mysqldump client uses the "SHOW CREATE DATABASE" query to
  obtain the "CREATE DATABASE" statement from that database.
  The 4.x server doesn't recognise that query, and mysqldump
  forms the "CREATE DATABASE" statement from scratch.
  That statement was formed incorrectly.
  
  To enforce the mysqldump client to create that statement from
  scratch, debugging code has been added to the mysql_execute_command
  function: in tcase of the --loose-debug=d,4x_server_emul option,
  the server returns parse error to client to emulate old behaviour.
  
  The 4x_server_emul test case option has been added for use with the
  DBUG_EXECUTE_IF debugging macro. This option affects debug server
  builds only to emulate particular behavior of a 4.x server for
  the mysqldump client testing. Non-debugging builds are not affected.
client/mysqldump.c:
  Fixed bug #30126.
  The init_dumping_tables function has been modified to output semicolon
  outside of commentaries.
2007-08-31 16:59:07 +05:00
unknown
3f9be28c41 Merge weblab.(none):/home/marcsql/TREE/mysql-5.0-base
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-runtime


sql/item_cmpfunc.h:
  Auto merged
sql/sql_lex.cc:
  Auto merged
2007-08-30 17:23:40 -06:00
unknown
672c421b13 Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-28779-b
2007-08-30 10:38:20 -06:00
unknown
bb986a24e7 Bug #30164: Using client side macro inside server side comments generates broken queries
Problem:
  
In cases when a client-side macro appears inside a server-side comment, the add_line() function in mysql.cc discarded all characters until the next delimiter to remove macro arguments from the query string. This resulted in broken queries being sent to the server when the next delimiter character appeared past the comment's boundaries, because the comment closing sequence ('*/') was discarded.
  
Fix:
  
If a client-side macro appears inside a server-side comment, discard all characters in the comment after the macro (that is, until the end of the comment rather than the next delimiter).
This is a minimal fix to allow only simple cases used by the mysqlbinlog utility. Limitations that are worth documenting:
  
- Nested server-side and/or client-side comments are not supported by mysql.cc
- Using client-side macros in multi-line server-side comments is not supported
- All characters after a client-side macro in a server-side comment will be omitted from the query string (and thus, will not be sent to server).


client/mysql.cc:
  If a client-side macro appears inside a server-side comment, discard all characters in the comment after the macro.
mysql-test/r/mysql.result:
  Added a test case for bug #30164.
mysql-test/t/mysql.test:
  Added a test case for bug #30164.
2007-08-30 12:53:24 +04:00
unknown
b0f899e977 Bug#28779 (mysql_query() allows execution of statements with unbalanced
comments)

Before this fix, the server would accept queries that contained comments,
even when the comments were not properly closed with a '*' '/' marker.

For example,
  select 1 /* + 2 <EOF>
would be accepted as
  select 1 /* + 2 */ <EOF>
and executed as
  select 1

With this fix, the server now rejects queries with unclosed comments
as syntax errors.
Both regular comments ('/' '*') and special comments ('/' '*' '!') must be
closed with '*' '/' to be parsed correctly.


mysql-test/r/comments.result:
  Unbalanced comments are a syntax error.
mysql-test/t/comments.test:
  Unbalanced comments are a syntax error.
sql/sql_lex.cc:
  Unbalanced comments are a syntax error.
2007-08-29 14:50:32 -06:00
unknown
3d5440505c Test case for Bug#13675: DATETIME/DATE type in store proc param
seems to be converted as varbinary.

The bug has been already fixed. This CS just adds a test case for it.


mysql-test/r/sp.result:
  Update result file.
mysql-test/t/sp.test:
  Test case for BUG#13675.
2007-08-29 14:57:59 +04:00
unknown
bd1f34d932 Merge gkodinov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  magare.gmz:/home/kgeorge/mysql/autopush/B30377-5.0-opt


sql/sql_select.cc:
  Auto merged
2007-08-29 12:47:24 +03:00
unknown
bdf19dc73b Merge mhansson@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  linux-st28.site:/home/martin/mysql/src/bugx/my50-bugx


mysql-test/t/innodb_mysql.test:
  Auto merged
sql/sql_select.cc:
  Auto merged
mysql-test/r/innodb_mysql.result:
  SCCS merged
2007-08-29 10:49:19 +02:00
unknown
901ead6cb5 Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime
2007-08-28 18:47:08 -03:00
unknown
e0e44ad66e Bug#30625 (Performance, reduce depth for expressions)
This is a performance bug, affecting in particular the bison generated code
for the parser.

Prior to this fix, the grammar used a long chain of reduces to parse an
expression, like:
  bit_expr -> bit_term
  bit_term -> bit_factor
  bit_factor -> value_expr
  value_expr -> term
  term -> factor
etc

This chain of reduces cause the internal state automaton in the generated
parser to execute more state transitions and more reduces, so that the
generated MySQLParse() function would spend a lot of time looping to execute
all the grammar reductions.

With this patch, the grammar has been reorganized so that rules are more
"flat", limiting the depth of reduces needed to parse <expr>.

Tests have been written to enforce that relative priorities and properties
of operators have not changed while changing the grammar.

See the bug report for performance data.


mysql-test/r/parser_precedence.result:
  Improved test coverage for operator precedence
mysql-test/t/parser_precedence.test:
  Improved test coverage for operator precedence
sql/sql_yacc.yy:
  Simplified the grammar to improve performances
2007-08-28 11:16:03 -06:00
unknown
310afbd4a9 Bug #30377: EXPLAIN loses last_query_cost when used with UNION
Currently the Last_query_cost session status variable shows
only the cost of a single flat subselect. For complex queries
(with subselects or unions etc) Last_query_cost is not valid
as it was showing the cost for the last optimized subselect.
Fixed by reseting to zero Last_query_cost when the complete
cost of the query cannot be determined.
Last_query_cost will be non-zero only for single flat queries.


mysql-test/r/status.result:
  Bug #30377: test case
mysql-test/t/status.test:
  Bug #30377: test case
sql/sql_lex.h:
  Bug #30377: helper function
sql/sql_select.cc:
  Bug #30377: don't assign cost if not on single level statement
2007-08-28 18:51:03 +03:00
unknown
d54f42c16c Merge ramayana.hindu.god:/home/tsmith/m/bk/50
into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50


sql/sql_show.cc:
  Auto merged
2007-08-27 18:19:55 -06:00
unknown
2368664681 Bug #30596 GROUP BY optimization gives wrong result order
The optimization that uses a unique index to remove GROUP BY, did not 
ensure that the index was actually used, thus violating the ORDER BY
that is impled by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
simply removed.


BitKeeper/etc/ignore:
  Added support-files/mysqld_multi.server tests/bug25714 cscope.in.out cscope.out cscope.po.out to the ignore list
mysql-test/r/distinct.result:
  Bug#30596: Changed test case. 
  Prior to Bug#16458, These queries use temp table and filesort. The
  bug was that they used a temp table. However, that patch removed
  filesort also, in which case we can no longer gurantee correct ordering.
mysql-test/r/group_by.result:
  Bug#30596: Correct result
mysql-test/r/innodb_mysql.result:
  Bug#30596: Test case for innodb. Here, as opposed to for MyISAM, row 
  lookup is done using index whenever the index covers the group list.
mysql-test/t/group_by.test:
  Bug#30596: Test case
mysql-test/t/innodb_mysql.test:
  Bug#30596: Test case
sql/sql_select.cc:
  Bug#30596: The fix, replacing GROUP BY with ORDER BY unless 
  ORDER BY [NULL|<constant>]
2007-08-27 17:33:41 +02:00
unknown
34ded62908 Bug#30632 HANDLER read failure causes hang
If, after the tables are locked, one of the conditions to read from a
HANDLER table is not met, the handler code wrongly jumps to a error path
that won't unlock the tables.

The user-visible effect is that after a error in a handler read command,
all subsequent handler operations on the same table will hang.

The fix is simply to correct the code to jump to the (same) error path that
unlocks the tables.


mysql-test/r/handler.result:
  Bug#30632 test case result
mysql-test/t/handler.test:
  Bug#30632 test case
sql/sql_handler.cc:
  Always unlock the internal and external table level locks if any of the conditions
  (including errors) to read from a HANDLER table are not met.
2007-08-27 10:37:12 -03:00
unknown
369a5f1cdc Bug#25164 create table a as select * from A hangs
The problem from a user's perspective: user creates table A, and then tries
to CREATE TABLE a SELECT from A - and this causes a deadlock error, a hang,
or fails with a debug assert, but only if the storage engine is InnoDB.

The origin of the problem: InnoDB uses case-insensitive collation
(system_charset_info) when looking up the internal table share, thus returning
the same share for 'a' and 'A'.

Cause of the user-visible behavior: since the same share is returned to SQL
locking subsystem, it assumes that the same table is first locked (within the
same session) for WRITE, and then for READ, and returns a deadlock error.
However, the code is wrong in not properly cleaning up upon an error, leaving
external locks in place, which leads to assertion failures and hangs.

Fix that has been implemented: the SQL layer should properly propagate the
deadlock error, cleaning up and freeing all resources.

Further work towards a more complete solution: InnoDB should not use case
insensitive collation for table share hash if table names on disk honor the case.


mysql-test/r/innodb-deadlock.result:
  Bug#25164 test case result
mysql-test/t/innodb-deadlock.test:
  Bug#25164 test case. The CREATE TABLE may fail depending on the character set
  of the system and filesystem, but it should never hang.
sql/lock.cc:
  Unlock the storage engine "external" table level locks, if the MySQL thr_lock
  locking subsystem detects a deadlock error.
2007-08-27 10:13:54 -03:00
unknown
e19f49ae5e Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  moonbone.local:/mnt/gentoo64/work/30245-bug-5.0-opt-mysql


sql/sql_select.cc:
  Auto merged
2007-08-24 22:11:23 +00:00
unknown
294a43ec5e Merge bk-internal.mysql.com:/data0/bk/mysql-5.0
into  bk-internal.mysql.com:/users/gshchepa/mysql-5.0-opt


sql/sql_base.cc:
  Auto merged
sql/sql_cache.cc:
  Auto merged
2007-08-23 21:28:33 +02:00
unknown
0ff829bb71 Merge pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-marvel
into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0.48


sql/sql_base.cc:
  Auto merged
sql/sql_cache.cc:
  Auto merged
2007-08-23 17:43:47 +02:00
unknown
d4e34c80d6 Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime
into  weblab.(none):/home/marcsql/TREE/mysql-5.0-30237


sql/sql_yacc.yy:
  Auto merged
2007-08-22 11:06:42 -06:00
unknown
fb1be0f1e5 Bug#30237 (Performance regression in boolean expressions)
This is a performance bug, related to the parsing or 'OR' and 'AND' boolean
expressions.

Let N be the number of expressions involved in a OR (respectively AND).

When N=1

For example, "select 1" involve only 1 term: there is no OR operator.

In 4.0 and 4.1, parsing expressions not involving OR had no overhead.
In 5.0, parsing adds some overhead, with Select->expr_list.

With this patch, the overhead introduced in 5.0 has been removed,
so that performances for N=1 should be identical to the 4.0 performances,
which are optimal (there is no code executed at all)

The overhead in 5.0 was in fact affecting significantly some operations.
For example, loading 1 Million rows into a table with INSERTs,
for a table that has 100 columns, leads to parsing 100 Millions of
expressions, which means that the overhead related to Select->expr_list
is executed 100 Million times ...

Considering that N=1 is by far the most probable expression,
this case should be optimal.

When N=2

For example, "select a OR b" involves 2 terms in the OR operator.

In 4.0 and 4.1, parsing expressions involving 2 terms created 1 Item_cond_or
node, which is the expected result.
In 5.0, parsing these expression also produced 1 node, but with some extra
overhead related to Select->expr_list : creating 1 list in Select->expr_list
and another in Item_cond::list is inefficient.

With this patch, the overhead introduced in 5.0 has been removed
so that performances for N=2 should be identical to the 4.0 performances.
Note that the memory allocation uses the new (thd->mem_root) syntax
directly.
The cost of "is_cond_or" is estimated to be neglectable: the real problem
of the performance degradation comes from unneeded memory allocations.

When N>=3

For example, "select a OR b OR c ...", which involves 3 or more terms.

In 4.0 and 4.1, the parser had no significant cost overhead, but produced
an Item tree which is difficult to evaluate / optimize during runtime.
In 5.0, the parser produces a better Item tree, using the Item_cond
constructor that accepts a list of children directly, but at an extra cost
related to Select->expr_list.

With this patch, the code is implemented to take the best of the two
implementations:
- there is no overhead with Select->expr_list
- the Item tree generated is optimized and flattened.

This is achieved by adding children nodes into the Item tree directly,
with Item_cond::add(), which avoids the need for temporary lists and memory
allocation

Note that this patch also provide an extra optimization, that the previous
code in 5.0 did not provide: expressions are flattened in the Item tree,
based on what the expression already parsed is, and not based on the order
in which rules are reduced.

For example : "(a OR b) OR c", "a OR (b OR c)" would both be represented
with 2 Item_cond_or nodes before this patch, and with 1 node only with this
patch. The logic used is based on the mathematical properties of the OR
operator (it's associative), and produces a simpler tree.


sql/item_cmpfunc.h:
  Improved performances for parsing boolean expressions
sql/sql_yacc.yy:
  Improved performances for parsing boolean expressions
mysql-test/r/parser_precedence.result:
  Added test cases to cover boolean operator precedence
mysql-test/t/parser_precedence.test:
  Added test cases to cover boolean operator precedence
2007-08-22 11:05:35 -06:00
unknown
abc02d7e47 Merge adventure.(none):/home/thek/Development/cpp/bug30269/my50-bug30269
into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime


mysql-test/r/query_cache.result:
  Auto merged
mysql-test/t/query_cache.test:
  Auto merged
2007-08-21 17:47:06 +02:00
unknown
521529be29 Merge sgluhov@bk-internal.mysql.com:/home/bk/mysql-5.0-opt
into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt
2007-08-21 17:57:48 +05:00
unknown
3a5a0ea392 Bug#30269 Query cache eats memory
Although the query cache doesn't support retrieval of statements containing
column level access control, it was still possible to cache such statements
thus wasting memory.
  
This patch extends the access control check on the target tables to avoid
caching a statement with column level restrictions. 

Views are excepted and can be cached but only retrieved by super user account.


mysql-test/t/query_cache_with_views.test:
  Rename: mysql-test/t/view_query_cache.test -> mysql-test/t/query_cache_with_views.test
mysql-test/r/query_cache_with_views.result:
  Rename: mysql-test/r/view_query_cache.result -> mysql-test/r/query_cache_with_views.result
mysql-test/r/query_cache.result:
  Modified test case to allow caching of views
mysql-test/t/query_cache.test:
  Modified test case to allow caching of views
sql/sql_cache.cc:
  Allow caching of views
2007-08-21 13:43:09 +02:00
unknown
a9322f2e57 Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt


sql/sql_base.cc:
  Auto merged
2007-08-21 16:31:30 +05:00
unknown
63a95f331a Merge gleb.loc:/home/uchum/work/bk/5.0
into  gleb.loc:/home/uchum/work/bk/5.0-opt
2007-08-21 16:14:46 +05:00