- developers - lists.mariadb.org

Re: [Maria-developers] really annoying bug in mysql 5.0/5.1 optimiser, opened for more than 2 years, and still present in MariaDB
by Jocelyn Fournier 23 Nov '10

23 Nov '10

Hi, Just FYI, it's created as https://bugs.launchpad.net/maria/+bug/639949 I really hope it could be fixed soon, since it could impact mysql performances for a lot of customers. Thanks and regards, Jocelyn Fournier Le 15/09/2010 18:43, Igor Babaev a écrit : > Jocelyn Fournier wrote: >> Hi Igor, >> >> Just curious, is there any bug corresponding to this issue in launchpad ? > Hi Jocelyn, > > No, feel yourself free to add it for MariaDB 5.1. In this case the > chances are higher that the problem will be fixed in one of the nearest > releases. > > Regards, > Igor. > >> Thanks ! >> Jocelyn >> >> >> Le 27/08/10 18:04, Igor Babaev a écrit : >>> Jocelyn Fournier wrote: >>>> Hi, >>>> >>>> There's a really annoying bug in the mysql optimiser existing for a >>>> really long time now, and which has a direct impact on performances : >>>> >>>> http://bugs.mysql.com/bug.php?id=36817 >>>> >>>> Since MySQL definitly doesn't seem to want to fix it, I hope MariaDB >>>> could do something to help the poor developpers who need to heavily hack >>>> there apps with USE INDEX ;) >>>> >>>> Note I've tested with mariadb 5.2.1-beta, and the bug is still present. >>>> >>>> Thanks a lot ! >>>> Jocelyn Fournier >>> Jocelyn, >>> >>> I will take care of this bug. >>> >>> Regards, >>> Igor. >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~maria-developers >>>> Post to : maria-developers(a)lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~maria-developers >>>> More help : https://help.launchpad.net/ListHelp >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~maria-developers >>> Post to : maria-developers(a)lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~maria-developers >>> More help : https://help.launchpad.net/ListHelp >

1 0

[Maria-developers] Buildbot Outage
by Adam M. Dutko 22 Nov '10

22 Nov '10

Sorry for the delayed notice but adutko-centos5-amd64 will probably be offline until Wednesday (11/24/10) awaiting a part replacement. -Adam <http://buildbot.askmonty.org/buildbot/buildslaves/adutko-centos5-amd64>

1 0

Re: [Maria-developers] [Commits] Rev 2832: Fix for LP BUG#606013: Adding bit field support for heap tables. in file:///home/bell/maria/bzr/work-maria-5.3-lp606013/
by Michael Widenius 22 Nov '10

22 Nov '10

Hi! Here is a review of this <cut> > --- a/storage/heap/hp_create.c 2010-08-05 19:56:11 +0000 > +++ b/storage/heap/hp_create.c 2010-11-16 21:03:26 +0000 > @@ -104,6 +104,13 @@ int heap_create(const char *name, uint k > */ > keyinfo->seg[j].type= HA_KEYTYPE_VARTEXT1; > break; > + case HA_KEYTYPE_BIT: > + /* > + The odd bits which stored separately (if they are present > + (bit_pos, bit_length)) are already present in seg[j].length as > + additional byte. Add: See field.h, function key_length() <cut> > @@ -720,7 +765,8 @@ uint hp_rb_make_key(HP_KEYDEF *keydef, u > { > uint length= seg->length; > uchar *pos= (uchar*) rec + seg->start; > - > + DBUG_ASSERT(seg->type != HA_KEYTYPE_BIT); Add a check in the test suite that one can't create a rb key with bit fields. Add also a MRT for this. (you can probable reuse something from type_bit.test and archive_bitfield.test for this) Regards, Monty

1 0

[Maria-developers] Problem with prep_where (LP BUG#675248)
by Oleksandr Byelkin 22 Nov '10

22 Nov '10

Preparation statement for PS looks like this (example uses prep_where, but we have the same problem for other parts stored in st_select_lex::fix_prepare_information()): ... conds->fix_fields(...&conds...) /* (1.1) JOIN::prepare()*/ ... prep_where= *conds; /* (1.2) st_select_lex::fix_prepare_information() */ *conds= where= prep_where->copy_andor_structure() ... Then executing of the prepared statement is like this: where= prep_where->copy_andor_structure() /* (2.1) reinit_stmt_before_use */ ... where->fix_fields() /* (2.2) JOIN::prepare() */ ... The problem is that during (1.1) we could substitute conds with reference on other item (for example if we change reference on Item_field on Item_ref* or Item_ref on Item_field). The new item will be destroyed after preparation (i.e before (2.1)). So during (2.1) prep_where points on freed memory. How to solve the problem. 1. Workarounds 1.1. Make changing Items inherited from Item_ident (Item_field and Item_ref*) during resolving permanent. Pros: - Looks logical - reduce work during second preparation Cons: - Play with statement memory usually complex enough. - have to be sure that there is no any reference on the original Item 1.2 Add new method for Item, which return 'this' pointer but for Item_idents creating during resolving original Item. (1.2) turns to something like: prep_where= (*conds)->original_ident_item(); Pros: - Looks simple Cons: - Item already overloaded with methods like this 1.3 Assign prep_where before (1.1) Pros: - Easy to implement Cons: - Need changing logic and semantic of some calls and prep_where/prep_having... class variables. 2. Global solutions for the problem of double/triple/... reference on transformed expression (it is not applicadle for 5.1-5.3 but could de universal solution in 5.5 of higher): 2.1 Absolutely transparent wrapper to save only one reference on any expression which could be transformed: Pros: - Could base class for many other wrappers Cons: - It is difficult to implement such absolutely transparent wrapper. - A lot of places where it should be put, make Item tree bigger 2.2 Turn THD::change_list to hash (for example) and chack presence of assigning variable in the list, if it found, also register changing for variable we are assigning value now. For example instead of prep_where= *conds; use thd->assign_changeable(&prep_where, conds), where: void THD::assign_changeable(void **newref, void **oldref) { if (in_changed_references(oldref) change_item_tree(newref, *oldref); else *newref= *oldref; } Pros: - no additional work for usual statements Cons: - List supports order of assigments easyly, but hash can't - time for finding pointers in the hash

2 1

Re: [Maria-developers] [Commits] Rev 89: MBug#674413: better fix following review: clear sql_mode rather than add every column explicitly. in http://bazaar.launchpad.net/~maria-captains/maria/5.1
by Sergei Golubchik 21 Nov '10

21 Nov '10

Hi, knielsen! On Nov 20, knielsen(a)knielsen-hq.org wrote: > At http://bazaar.launchpad.net/~maria-captains/maria/5.1 > > ------------------------------------------------------------ > revno: 89 > revision-id: knielsen(a)knielsen-hq.org-20101120084531-x0hbb64q9x0yj376 > parent: knielsen(a)knielsen-hq.org-20101119133933-wb5g8sdjynao018w > committer: knielsen(a)knielsen-hq.org > branch nick: ourdelta-montyprogram-fixes > timestamp: Sat 2010-11-20 09:45:31 +0100 > message: > MBug#674413: better fix following review: clear sql_mode rather than add every column explicitly. > === modified file 'bakery/debian-5.2/dist/Debian/mariadb-server-5.2.postinst' > --- a/bakery/debian-5.2/dist/Debian/mariadb-server-5.2.postinst 2010-11-19 13:39:33 +0000 > +++ b/bakery/debian-5.2/dist/Debian/mariadb-server-5.2.postinst 2010-11-20 08:45:31 +0000 > @@ -195,6 +195,7 @@ EOF > "ALTER TABLE user CHANGE Password Password char(41) character set latin1 collate latin1_bin DEFAULT '' NOT NULL"`; > replace_query=`/bin/echo -e \ > "USE mysql\n" \ > + "SET sql_mode='';\n" \ > "REPLACE INTO user SET " \ > " host='localhost', user='debian-sys-maint', password=password('$pass'), " \ > " Select_priv='Y', Insert_priv='Y', Update_priv='Y', Delete_priv='Y', " \ > @@ -205,9 +206,7 @@ EOF > " Repl_slave_priv='Y', Repl_client_priv='Y', Create_view_priv='Y', "\ > " Show_view_priv='Y', Create_routine_priv='Y', Alter_routine_priv='Y', "\ > " Create_user_priv='Y', Event_priv='Y', Trigger_priv='Y',"\ > - " ssl_type='', ssl_cipher='', x509_issuer='', x509_subject='',"\ > - " max_questions=0, max_updates=0, max_connections=0,"\ > - " max_user_connections=0, plugin='', auth_string='';"`; > + " ssl_cipher='', x509_issuer='', x509_subject='';"`; There's no need to set ssl_cipher and other blob columns - they'll get the empty string by default anyway. Regards, Sergei

2 1

[Maria-developers] Problem with MariaDb as a Windows service
by Peter Laursen 20 Nov '10

20 Nov '10

Some person claimed here around one week ago that MariaDB would not run as service after "mysqld --install". I replied that it worked for me - but it does not with the latest stable version 5.2.3 (it did with the 5.2.3 RC) (so my apology to this person!) Windows console output: C:\maria52\bin>sc delete maria52 [SC] DeleteService LYKKEDES C:\maria52\bin>mysqld --install maria52 Service successfully installed. C:\maria52\bin>net start maria52 Tjenesten maria52 starter... Tjenesten maria52 kunne ikke startes. Der opstod en systemfejl. Systemfejlen 1067 opstod. (From Danish --> service could not start --> the system error 1067 occurred) I have tried with both old datadir and the empty one shipped with mariaDB and also my old my.ini as well as a fresh one. Also I tried to add --defaults-dir to the registry (just in case I had overlooked a my.ini copy in C:\ or C:\Windows) and adding doublequotes key manually like "C:\maria52\bin\mysqld" --defaults-file="C:\maria52\my.ini" maria52 I double checked there are no conflicts wit all settings. The command "C:\maria52\bin\mysqld" --defaults-file="C:\maria52\my.ini" .. starts the server (also when --defaults-file is omitted) .. but not as a service of course. Was it tested with the 5.2.3 GA release that it will run as a Windows service? The RC worked as a charm - but the GA will not. Any idea? (I am using Win7, 64 bit, Home Premium) Peter (Webyog)

2 6

[Maria-developers] MariaDB 5.1.51
by Daniel Bartholomew 20 Nov '10

20 Nov '10

All, I've created the download, release notes, and changelog pages for MariaDB 5.1.51: http://askmonty.org/wiki/MariaDB:Download:MariaDB_5.1.51 http://kb.askmonty.org/v/mariadb-5151-release-notes http://kb.askmonty.org/v/mariadb-5151-changelog Apart from the CentOS packages, the mirrors should now have all of the files for this release. There was an issue with the signing key used on the CentOS packages. The issue has been fixed and the updated packages are seeding now. If you can't wait, the osuosl.org mirror is the primary one and is always up-to-date. Please let me know if anything is missing from the release notes or changelog, or if there are any errors. If you have editing rights, feel free to make the corrections or additions directly; otherwise, please let me know of needed changes here or on IRC. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

2 3

Re: [Maria-developers] Fwd: [Commits] Rev 2860: Fixed LP bug #675922. in file:///home/igor/maria/maria-5.3-mwl128-bug675922/
by Sergey Petrunya 19 Nov '10

19 Nov '10

Hello Igor, On Thu, Nov 18, 2010 at 10:04:24PM -0800, Igor Babaev wrote: > Sergey, > > Please review this fix. > Ok to push after the irc feedback (lack of comments about JOIN_CACHE format) is addressed. > > -------- Original Message -------- > Subject: [Commits] Rev 2860: Fixed LP bug #675922. in > file:///home/igor/maria/maria-5.3-mwl128-bug675922/ > Date: Thu, 18 Nov 2010 22:02:41 -0800 (PST) > From: Igor Babaev <igor(a)askmonty.org> > Reply-To: maria-developers(a)lists.launchpad.net > To: <commits(a)mariadb.org> > > > > At file:///home/igor/maria/maria-5.3-mwl128-bug675922/ > > ------------------------------------------------------------ > revno: 2860 > revision-id: igor(a)askmonty.org-20101119060240-gzh1k5gxl3aazk45 > parent: igor(a)askmonty.org-20101118221357-zg55d3erru07ugzy > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.3-mwl128-bug675922 > timestamp: Thu 2010-11-18 22:02:40 -0800 > message: > Fixed LP bug #675922. > The bug happened when BKA join algorithm used an incremental buffer > and some of the fields over which access keys were constructed > - were allocated in the previous join buffers > - were non-nullable > - belonged to inner tables of outer joins. > For such fields an offset to the field value in the record is saved > in the postfix of the record, and a zero offset indicates that the value > is null. Before the key using the field value is constructed the > value is read into the corresponding field of the record buffer and > the null bit is set for the field if the offset is 0. However if > the field is non-nullable the table->null_row must be set to 1 > for null values and to 0 for non-null values to ensure proper reading > of the value from the record buffer. > > === modified file 'mysql-test/r/join_cache.result' > --- a/mysql-test/r/join_cache.result 2010-11-18 22:13:57 +0000 > +++ b/mysql-test/r/join_cache.result 2010-11-19 06:02:40 +0000 > @@ -6004,4 +6004,56 @@ > SET SESSION optimizer_switch = 'outer_join_with_cache=off'; > SET SESSION join_cache_level = DEFAULT; > DROP TABLE t1,t2,t3; > +# > +# Bug #675922: incremental buffer for BKA with access from previous > +# buffers from non-nullable columns whose values may be null > +# > +CREATE TABLE t1 (a1 varchar(32)) ; > +INSERT INTO t1 VALUES ('s'),('k'); > +CREATE TABLE t2 (a2 int PRIMARY KEY, b2 varchar(32)) ; > +INSERT INTO t2 VALUES (7,'s'); > +CREATE TABLE t3 (a3 int PRIMARY KEY, b3 varchar(32)) ; > +INSERT INTO t3 VALUES (7,'s'); > +CREATE TABLE t4 (a4 int) ; > +INSERT INTO t4 VALUES (9); > +CREATE TABLE t5(a5 int PRIMARY KEY, b5 int) ; > +INSERT INTO t5 VALUES (7,0); > +SET SESSION optimizer_switch = 'outer_join_with_cache=on'; > +SET SESSION join_cache_level = 0; > +EXPLAIN > +SELECT t4.a4, t5.b5 > +FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > +LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE t1 ALL NULL NULL NULL NULL 2 > +1 SIMPLE t2 ALL PRIMARY NULL NULL NULL 1 Using where > +1 SIMPLE t3 eq_ref PRIMARY PRIMARY 4 test.t2.a2 1 Using index > +1 SIMPLE t4 ALL NULL NULL NULL NULL 1 Using where > +1 SIMPLE t5 eq_ref PRIMARY PRIMARY 4 test.t2.a2 1 Using where > +SELECT t4.a4, t5.b5 > +FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > +LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +a4 b5 > +9 0 > +9 NULL > +SET SESSION join_cache_level = 6; > +EXPLAIN > +SELECT t4.a4, t5.b5 > +FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > +LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE t1 ALL NULL NULL NULL NULL 2 > +1 SIMPLE t2 ALL PRIMARY NULL NULL NULL 1 Using where > +1 SIMPLE t3 eq_ref PRIMARY PRIMARY 4 test.t2.a2 1 Using index > +1 SIMPLE t4 ALL NULL NULL NULL NULL 1 Using where; Using join buffer (flat, BNL join) > +1 SIMPLE t5 eq_ref PRIMARY PRIMARY 4 test.t2.a2 1 Using where; Using join buffer (incremental, BKA join) > +SELECT t4.a4, t5.b5 > +FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > +LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +a4 b5 > +9 0 > +9 NULL > +SET SESSION optimizer_switch = 'outer_join_with_cache=off'; > +SET SESSION join_cache_level = DEFAULT; > +DROP TABLE t1,t2,t3,t4,t5; > set @@optimizer_switch=@save_optimizer_switch; > > === modified file 'mysql-test/t/join_cache.test' > --- a/mysql-test/t/join_cache.test 2010-11-18 22:13:57 +0000 > +++ b/mysql-test/t/join_cache.test 2010-11-19 06:02:40 +0000 > @@ -2655,5 +2655,50 @@ > > DROP TABLE t1,t2,t3; > > +--echo # > +--echo # Bug #675922: incremental buffer for BKA with access from previous > +--echo # buffers from non-nullable columns whose values may be null > +--echo # > + > +CREATE TABLE t1 (a1 varchar(32)) ; > +INSERT INTO t1 VALUES ('s'),('k'); > + > +CREATE TABLE t2 (a2 int PRIMARY KEY, b2 varchar(32)) ; > +INSERT INTO t2 VALUES (7,'s'); > + > +CREATE TABLE t3 (a3 int PRIMARY KEY, b3 varchar(32)) ; > +INSERT INTO t3 VALUES (7,'s'); > + > +CREATE TABLE t4 (a4 int) ; > +INSERT INTO t4 VALUES (9); > + > +CREATE TABLE t5(a5 int PRIMARY KEY, b5 int) ; > +INSERT INTO t5 VALUES (7,0); > + > +SET SESSION optimizer_switch = 'outer_join_with_cache=on'; > + > +SET SESSION join_cache_level = 0; > +EXPLAIN > +SELECT t4.a4, t5.b5 > + FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > + LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +SELECT t4.a4, t5.b5 > + FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > + LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > + > +SET SESSION join_cache_level = 6; > +EXPLAIN > +SELECT t4.a4, t5.b5 > + FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > + LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > +SELECT t4.a4, t5.b5 > + FROM ((t1 LEFT JOIN (t2 JOIN t3 ON t2.a2 = t3.a3) ON t2.b2 = t1.a1) > + LEFT JOIN t4 ON t4.a4 <> 0) LEFT JOIN t5 ON t5.a5 = t2.a2; > + > +SET SESSION optimizer_switch = 'outer_join_with_cache=off'; > +SET SESSION join_cache_level = DEFAULT; > + > +DROP TABLE t1,t2,t3,t4,t5; > + > # this must be the last command in the file > set @@optimizer_switch=@save_optimizer_switch; > > === modified file 'sql/sql_join_cache.cc' > --- a/sql/sql_join_cache.cc 2010-11-13 15:47:43 +0000 > +++ b/sql/sql_join_cache.cc 2010-11-19 06:02:40 +0000 > @@ -1805,14 +1805,21 @@ > size_of_fld_ofs* > (referenced_fields+1-copy->referenced_field_no)); > bool is_null= FALSE; > + Field *field= copy->field; > if (offset == 0 && flag_fields) > is_null= TRUE; > if (is_null) > - copy->field->set_null(); > + { > + field->set_null(); > + if (!field->real_maybe_null()) > + field->table->null_row= 1; > + } > else > { > uchar *save_pos= pos; > - copy->field->set_notnull(); > + field->set_notnull(); > + if (!field->real_maybe_null()) > + field->table->null_row= 0; > pos= rec_ptr+offset; > read_record_field(copy, blob_data_is_in_rec_buff(rec_ptr)); > pos= save_pos; > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] Fwd: [Commits] Rev 2859: Fixed LP #bug 660963. in file:///home/igor/maria/maria-5.3-mwl128-bug660963/
by Sergey Petrunya 19 Nov '10

19 Nov '10

Hello Igor, On Thu, Nov 18, 2010 at 02:17:13PM -0800, Igor Babaev wrote: > Sergey, > > Please review this patch ASAP as this bug blocks Philip with testing. > If you have any questions contact me by skype. > Ok to push after the comment below is addressed. > -------- Original Message -------- > Subject: [Commits] Rev 2859: Fixed LP #bug 660963. in > file:///home/igor/maria/maria-5.3-mwl128-bug660963/ > Date: Thu, 18 Nov 2010 14:13:58 -0800 (PST) > From: Igor Babaev <igor(a)askmonty.org> > Reply-To: maria-developers(a)lists.launchpad.net > To: <commits(a)mariadb.org> > > > > At file:///home/igor/maria/maria-5.3-mwl128-bug660963/ > > ------------------------------------------------------------ > revno: 2859 > revision-id: igor(a)askmonty.org-20101118221357-zg55d3erru07ugzy > parent: igor(a)askmonty.org-20101116050732-hpbqelsf8nvae4xt > committer: Igor Babaev <igor(a)askmonty.org> > branch nick: maria-5.3-mwl128-bug660963 > timestamp: Thu 2010-11-18 14:13:57 -0800 > message: > Fixed LP #bug 660963. > The condition that was supposed to check whether a join table > is an inner table of a nested outer join or semi-join was not > quite correct in the code of the function check_join_cache_usage. > That's why some queries with nested outer joins triggered > an assertion failure. > Encapsulated this condition in the new method called > JOIN_TAB::is_nested_inner and provided a proper code for it. > > Also corrected a bug in the code of check_join_cache_usage() > that caused a downgrade of not first join buffers of the > level 5 and 7 to level 4 and 6 correspondingly. > ... > === modified file 'sql/sql_select.cc' > --- a/sql/sql_select.cc 2010-11-16 05:07:32 +0000 > +++ b/sql/sql_select.cc 2010-11-18 22:13:57 +0000 > @@ -7635,8 +7635,7 @@ > if (cache_level == 0 || i == join->const_tables || !prev_tab) > return 0; > > - if (force_unlinked_cache && > - (cache_level & JOIN_CACHE_INCREMENTAL_BIT)) > + if (force_unlinked_cache && (cache_level%2 == 0)) > cache_level--; > > if (options & SELECT_NO_JOIN_CACHE) > @@ -7658,13 +7657,14 @@ > /* > Non-linked join buffers can't guarantee one match > */ > - if ((force_unlinked_cache || cache_level == 1) && > - ((tab->is_inner_table_of_semi_join_with_first_match() && > - !tab->is_single_inner_of_semi_join_with_first_match()) || > - (tab->is_inner_table_of_outer_join() && > - !tab->is_single_inner_of_outer_join()))) > - goto no_join_cache; > - > + if (tab->is_nested_inner()) > + { > + if (force_unlinked_cache || cache_level == 1) > + goto no_join_cache; > + if (cache_level & 1) > + cache_level--; > + } > + > /* > Don't use join buffering if we're dictated not to by no_jbuf_after (this > ...) > @@ -7757,9 +7757,6 @@ > (cache_level <= 6 || no_hashed_cache)) > goto no_join_cache; > > - if (prev_tab->cache && cache_level==7) > - cache_level= 6; > - > if ((rows != HA_POS_ERROR) && !(flags & HA_MRR_USE_DEFAULT_IMPL)) > { > if (cache_level <= 6 || no_hashed_cache) > > === modified file 'sql/sql_select.h' > --- a/sql/sql_select.h 2010-11-13 14:13:34 +0000 > +++ b/sql/sql_select.h 2010-11-18 22:13:57 +0000 > @@ -359,6 +359,14 @@ > return (first_inner && first_inner->last_inner == this) || > last_sj_inner_tab == this; > } > + bool is_nested_inner() Please add a comment clarifying what this function checks. > + { > + if (first_inner && (first_inner != last_inner || first_upper)) > + return TRUE; > + if (first_sj_inner_tab && first_sj_inner_tab != last_sj_inner_tab) > + return TRUE; > + return FALSE; > + } > struct st_join_table *get_first_inner_table() > { > if (first_inner) > BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] Discussion on RQG test cases
by Philip Stoev 17 Nov '10

17 Nov '10

Hi, I have reviewed your demands with respect to the test cases that I file. Many of those have already been fixed and implemented, however on the items below I have received contradictory feedback and I can not do anything about them unless the controversies are resolved: > When an offending query is found, substitute all JOINs with STRAIGHT_JOINs > to ensure that the plan is preserved, then continue simplifying, My impression was that Igor was against STRAIGHT_JOINS. Also, I have reduced STRAIGHT_JOIN usage in testing because there are various wrong results that show up when STRAIGHT_JOIN is used. If you are willing to fix those, we can move forward with this idea. FORCE KEY can also be used to preserve the original query plan, but only if it is not held against me that it makes the query unrealistic. > Test the base/normal cases (what normal users will use) first, by > negotiating with the feature developer what are the boundaries that define > "normal". Unless someone defines "normal" or we obtain data sets and queries from users, this is not possible. > For instance set normal buffer sizes, do not use empty/single-row tables Please make up your mind. Timour has said that both empty and single row tables are important for testing. What if automatic simplification reduced some tables to empty or a single row? Should I add some of the rows back? > Test the boundary cases after the main cases have been fixed Define "boundary". Huge tables? Huge queries? Huge records? Unrealistic buffer sizes? I have been informed only about a single bug that can be called a boundary condition. Have there been any others? > Generate more realistic data in the sense that the generated data should > imitate FK relationships, think of real-life distributions of values. For > instance keys should be sufficiently selective, as they would be for > real-life data. (Igor: 7) This implies large data sets, which in turn implies that bugs will have larger test cases. At this time, what I see is zero tolerance for test cases larger than 5 rows. > Include both the original *and* the simplified test case in the bub report I can do this only if the original query and test case will not be held against me. We have been through this before and the large queries have proven to be a source of conflict. Philip Stoev

1 0