[Maria-developers] MDEV-9712 Performance degradation of nested NULLIF
Hello Sergei,
Please have a look into a draft fix for MDEV-9712.
The problem happens because in 10.1 execution time for various
recursive stages (like walk, update_used_table and
propagate_equal_fields) in NULLIF is O(recursion_level^2),
because complexity is doubled on every recursion level
when we copy args[0] to args[2].
This fix simplifies some stages to make them faster.
It reduced execution time from 144 seconds to 12 seconds.
The idea is just not to iterate through args[2] when
it's just a copy of args[0] in these stages:
- Item_func_nullif::walk
- Item_func_nullif::update_used_tables
I'm not fully sure that skipping args[2] is always correct though.
For some transformers it may not be correct.
Btw, walk() can be called from the partitioning code when arg_count is
still 2 rather than 3. Looks suspicious. Perhaps there is a hidden bug
behind that.
The remaining heavy piece of the code is:
Item* propagate_equal_fields(THD *thd, const Context &ctx, COND_EQUAL
*cond)
{
Context cmpctx(ANY_SUBST, cmp.compare_type(), cmp.compare_collation());
args[0]->propagate_equal_fields_and_change_item_tree(thd, cmpctx,
cond, &args[0]);
args[1]->propagate_equal_fields_and_change_item_tree(thd, cmpctx,
cond, &args[1]);
args[2]->propagate_equal_fields_and_change_item_tree(thd,
Context_identity(),
cond, &args[2]);
return this;
}
We cannot use the same approach here, because args[0] and args[2]
are propagated with a different context (ANY_SUBST vs IDENTITY_SUBST).
Not sure what to do with this. Perhaps, data types could have an extra
attribute to tell that ANY_SUBST and IDENITTY_SUBST are equal.
So, for example, for non-ZEROFILL integers, ANY_SUBST and IDENTITY_SUBST
do the same thing and thus propagation could be done one time only.
But this would be a partial solution, for a limited number of data types.
Another option is to leave propagation as is.
Another option is do nothing at all.
If we rewrite the reported query as CASE, it will look heavy indeed.
So it's Ok to expect heavy execution complexity.
Thanks.
diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc
index 1ce8bad..35014ed 100644
--- a/sql/item_cmpfunc.cc
+++ b/sql/item_cmpfunc.cc
@@ -2503,6 +2503,23 @@ void Item_func_nullif::split_sum_func(THD *thd, Item **ref_pointer_array,
}
+bool Item_func_nullif::walk(Item_processor processor,
+bool walk_subquery, uchar *arg)
+{
+ /*
+No needs to iterate through args[2] when it's just a copy of args[0].
+See MDEV-9712 Performance degradation of nested NULLIF
+ */
+ uint tmp_count= arg_count == 2 || args[0] == args[2] ? 2 : 3;
+ for (uint i= 0; i < tmp_count; i++)
+ {
+if (args[i]->walk(processor, walk_subquery, arg))
+ return true;
+ }
+ return (this->*processor)(arg);
+}
+
+
void Item_func_nullif::update_used_tables()
{
if (m_cache)
@@ -2513,7 +2530,14 @@ void Item_func_nullif::update_used_tables()
}
else
{
-Item_func::update_used_tables();
+/*
+ No needs to iterate through args[2] when it's just a copy of args[0].
+ See MDEV-9712 Performance degradation of nested NULLIF
+*/
+DBUG_ASSERT(arg_count == 3);
+used_tables_and_const_cache_init();
+used_tables_and_const_cache_update_and_join(args[0] == args[2] ? 2 : 3,
+args);
}
}
diff --git a/sql/item_cmpfunc.h b/sql/item_cmpfunc.h
index 39f2cf5..ca5fc67 100644
--- a/sql/item_cmpfunc.h
+++ b/sql/item_cmpfunc.h
@@ -1026,6 +1026,7 @@ class Item_func_nullif :public Item_func_hybrid_field_type
String *str_op(String *str);
my_decimal *decimal_op(my_decimal *);
void fix_length_and_dec();
+ bool walk(Item_processor processor, bool walk_subquery, uchar *arg);
uint decimal_precision() const { return args[2]->decimal_precision(); }
const char *func_name() const { return "nullif"; }
void print(String *str, enum_query_type query_type);
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Gsoc 2016 Mdev 371 Unique index for blob
Hi, Sachin! On Mar 22, Sachin Setia wrote: > Hello Sergei > Actually I was prototyping for blob and varchar for aria and myisam > storage engine. > My prototype worked for complex definations like > craete table(abc int primary key, blob_col blob unique, varchar_col > varchar(1000) unique) engine=myisam; > Solved the issue of frm file incosistance. > > As you suggested for doing it for innodb i am current working on it.Innodb *I* did not suggest that. But you're welcome to try, of course. If you think that just MyISAM is too simple for a three month project. (Aria doesn't count it's a couple of days after you done MyISAM). > does not natively support hash based index. > when we run select distinct column from tbl; > it use create_internal_tmp_table() which uses maria storage engine for > creating tmp table. > But query like this works > MariaDB [sachin]> create table iu2(abc blob unique); > Query OK, 0 rows affected (0.04 sec) > > MariaDB [sachin]> insert into iu2 values(1); > Query OK, 1 row affected (0.03 sec) > > MariaDB [sachin]> insert into iu2 values(1); > ERROR 1062 (23000): Duplicate entry '1' for key 'abc' > this query does not use hash but it simply compares values Interesting. > Will write a proposal shortly. Okay. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] More memory allocation for key seg
Hi, Sachin! On Mar 22, Sachin Setia wrote: > Hello Devlopers > I was debugging the source code of mariadb. My query was > MariaDB [sachin]> create table pro2(abc int primary key,xyz int , > ass int ,unique(xyz,ass))engine=myisam; > > In table2myisam function of file ha_myisam.cc i found that > we are allocating more memory for keysegments > > if (!(my_multi_malloc(MYF(MY_WME), > recinfo_out, (share->fields * 2 + 2) * sizeof(MI_COLUMNDEF), > keydef_out, share->keys * sizeof(MI_KEYDEF), > &keyseg, > (share->key_parts + share->keys) * sizeof(HA_KEYSEG), >^ here why this > NullS))) > > And we donot use these extra key segments because > suceeding for loop use only total number of share->key_parts > keysegments. And same in ha_maria file.Is this a bug or I am missing > something > Regards > sachin The last key segment of every key is the row id. For dynamic row format it's the offset in the MYD file. For static row format (all rows have the same length as in your example above) it's the row number. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please review MDEV-9604 crash in Item::save_in_field with empty enum value
Hi Sergei, On 03/22/2016 09:48 PM, Sergei Golubchik wrote: > Hi, Alexander! > > On Mar 22, Alexander Barkov wrote: >> On 03/22/2016 09:33 PM, Sergei Golubchik wrote: >>> Hi, Alexander! >>> >>> On Mar 22, Alexander Barkov wrote: Hi Sergei, It fixes the reported crash, and additionally inconsistencies when comparing temporal columns to empty strings: In some cases it returned rows, in other cases it returned no rows, depending on: - the engine - the type of comparison arguments (columns vs literals). - presence of an index Now everything works in the same way. Note, this additional problem is not 10.1 specific, it existed in 10.0. But 10.0 and 10.1 worked differently in certain cases. >>> >>> Ok to push. In 10.0, right? >> >> The patch depends on my earlier changes in equal field propagation in >> 10.1. Okey to push to 10.1 only? > > It means that 10.0 patch won't merge into 10.1 anyway. > Yes, push into 10.1 then and please create a bug report for 10.0. Sure. I'll file a separate report for 10.0. Just to clarify: in 10.0 it does not crash. It only returns non-consistent results when comparing temporal columns to empty strings. So the problem is less serious. > Don't spend time on fixing it now, though, 10.0 release is still few weeks > ahead. Okey. > > > Regards, > Sergei > Chief Architect MariaDB > and secur...@mariadb.org > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please review MDEV-9604 crash in Item::save_in_field with empty enum value
Hi, Alexander! On Mar 22, Alexander Barkov wrote: > On 03/22/2016 09:33 PM, Sergei Golubchik wrote: > > Hi, Alexander! > > > > On Mar 22, Alexander Barkov wrote: > >> Hi Sergei, > >> > >> It fixes the reported crash, and additionally > >> inconsistencies when comparing temporal columns to empty strings: > >> > >> In some cases it returned rows, in other cases it returned no rows, > >> depending on: > >> - the engine > >> - the type of comparison arguments (columns vs literals). > >> - presence of an index > >> > >> Now everything works in the same way. > >> > >> Note, this additional problem is not 10.1 specific, it existed in 10.0. > >> But 10.0 and 10.1 worked differently in certain cases. > > > > Ok to push. In 10.0, right? > > The patch depends on my earlier changes in equal field propagation in > 10.1. Okey to push to 10.1 only? It means that 10.0 patch won't merge into 10.1 anyway. Yes, push into 10.1 then and please create a bug report for 10.0. Don't spend time on fixing it now, though, 10.0 release is still few weeks ahead. Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please review MDEV-9604 crash in Item::save_in_field with empty enum value
Hi Sergei, On 03/22/2016 09:33 PM, Sergei Golubchik wrote: > Hi, Alexander! > > On Mar 22, Alexander Barkov wrote: >> Hi Sergei, >> >> It fixes the reported crash, and additionally >> inconsistencies when comparing temporal columns to empty strings: >> >> In some cases it returned rows, in other cases it returned no rows, >> depending on: >> - the engine >> - the type of comparison arguments (columns vs literals). >> - presence of an index >> >> Now everything works in the same way. >> >> Note, this additional problem is not 10.1 specific, it existed in 10.0. >> But 10.0 and 10.1 worked differently in certain cases. > > Ok to push. In 10.0, right? The patch depends on my earlier changes in equal field propagation in 10.1. Okey to push to 10.1 only? > > And, by the way, please send a full commit next time, not just a diff. > It was quite a challenge to figure out what was the bug and what were > you fixing without a commit comment :( Thanks. Agreed. > > Regards, > Sergei > Chief Architect MariaDB > and secur...@mariadb.org > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Please review MDEV-9604 crash in Item::save_in_field with empty enum value
Hi, Alexander! On Mar 22, Alexander Barkov wrote: > Hi Sergei, > > It fixes the reported crash, and additionally > inconsistencies when comparing temporal columns to empty strings: > > In some cases it returned rows, in other cases it returned no rows, > depending on: > - the engine > - the type of comparison arguments (columns vs literals). > - presence of an index > > Now everything works in the same way. > > Note, this additional problem is not 10.1 specific, it existed in 10.0. > But 10.0 and 10.1 worked differently in certain cases. Ok to push. In 10.0, right? And, by the way, please send a full commit next time, not just a diff. It was quite a challenge to figure out what was the bug and what were you fixing without a commit comment :( Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] GSoC 2016:Unique indexes for blobs
Hello Sergei, I understood most of the internals of long unique constraints in MyISAM. I am still going through the code in InnoDB. I will soon reply to you. Thanks, Shubham On 21 March 2016 at 16:37, Sergei Golubchik wrote: > Hi, Shubham! > > On Mar 21, Shubham Barai wrote: > > > > I am currently looking into InnoDB codebase to see if it is possible > > for me to extend this feature to InnoDB storage engine. As InnoDB > > doesn't support this feature internally, it would require more time > > than MyISAM. Any suggestions regarding this would be helpful. > > Heh, that's very good (and ambitious) :) > > Do you already know how MyISAM supports arbitrary long UNIQUE > constraints internally? It stores only the hash of the value (of the > blob, for example) in the non-unique index, and on INSERT it checks if > there are identical hashes in the index. If there are (hash collision) > it will retrieve the rows and compare actual blob values. > > It seems that InnoDB should use the same approach as MyISAM. It'll need > some care for a case when two concurrent transactions insert conflicting > rows - as transaction changes are not visible until commit, you won't > see the conflict until it's too late. But gap locks [1] should be able > to prevent that. > > Regards, > Sergei > Chief Architect MariaDB > and secur...@mariadb.org > > [1] https://dev.mysql.com/doc/refman/5.7/en/innodb-record-level-locks.html > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] More memory allocation for key seg
Hello Devlopers I was debugging the source code of mariadb. My query was MariaDB [sachin]> create table pro2(abc int primary key,xyz int , ass int ,unique(xyz,ass))engine=myisam; In table2myisam function of file ha_myisam.cc i found that we are allocating more memory for keysegments if (!(my_multi_malloc(MYF(MY_WME), recinfo_out, (share->fields * 2 + 2) * sizeof(MI_COLUMNDEF), keydef_out, share->keys * sizeof(MI_KEYDEF), &keyseg, (share->key_parts + share->keys) * sizeof(HA_KEYSEG), ^ here why this NullS))) And we donot use these extra key segments because suceeding for loop use only total number of share->key_parts keysegments. And same in ha_maria file.Is this a bug or I am missing something Regards sachin ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Gsoc 2016 Mdev 371 Unique index for blob
Hello Sergei Actually I was prototyping for blob and varchar for aria and myisam storage engine. My prototype worked for complex definations like craete table(abc int primary key, blob_col blob unique, varchar_col varchar(1000) unique) engine=myisam; Solved the issue of frm file incosistance. As you suggested for doing it for innodb i am current working on it.Innodb does not natively support hash based index. when we run select distinct column from tbl; it use create_internal_tmp_table() which uses maria storage engine for creating tmp table. But query like this works MariaDB [sachin]> create table iu2(abc blob unique); Query OK, 0 rows affected (0.04 sec) MariaDB [sachin]> insert into iu2 values(1); Query OK, 1 row affected (0.03 sec) MariaDB [sachin]> insert into iu2 values(1); ERROR 1062 (23000): Duplicate entry '1' for key 'abc' this query does not use hash but it simply compares values Will write a proposal shortly. On Tue, Mar 22, 2016 at 4:20 PM, Sachin Setia wrote: > Hello Sergi > Actually I was prototyping for blob and varchar for aria and myisam > storage engine. > My prototype worked for complex definations like > craete table(abc int primary key, blob_col blob unique, varchar_col > varchar(1000) unique) engine=myisam; > Solved the issue of frm file incosistance. > > As you suggested for doing it for innodb i am current working on it.Innodb > does not natively support hash based index. > when we run select distinct column from tbl; > it use create_internal_tmp_table() which uses maria storage engine for > creating tmp table. > But query like this works > MariaDB [sachin]> create table iu2(abc blob unique); > Query OK, 0 rows affected (0.04 sec) > > MariaDB [sachin]> insert into iu2 values(1); > Query OK, 1 row affected (0.03 sec) > > MariaDB [sachin]> insert into iu2 values(1); > ERROR 1062 (23000): Duplicate entry '1' for key 'abc' > this query does not use hash but it simply compares values > Will write a proposal shortly. > > > Regards > sachin > > On Sat, Mar 19, 2016 at 1:52 AM, Sergei Golubchik > wrote: > >> Hi, Sachin! >> >> On Mar 18, Sachin Setia wrote: >> > >> > ERROR 1030 (HY000): Got error 190 "Incompatible key or row definition >> > between the MariaDB .frm file and the information in the storage engine. >> > You have to dump an" from storage engine MyISAM >> > >> > We are getting this becuase in mi_create for each unique_def it creates >> one >> > keydef and writes it.And this creates two problem >> > 1. frm keydef algorithm is different from saved kefdef algorithm(always >> > zero) for the time I have solved this problem . >> > >> > 2.Mismatch between keydef's keysegs the reason for this is when >> mi_create >> > creates keyseg for unique_def it did not keeps the orignal uniquedef's >> > keyseg parameters in mind like language start length which creates >> problem >> > in check_definition function in ha_myisam.cc.I am currently working on >> it >> > Once again sorry for this foolish mistake. >> > Regars >> > sachin >> >> No problem, everyone makes mistakes :) >> >> It's a prototype, after all. It's much more important that you >> understand how the code works and why it doesn't work. >> >> Regards, >> Sergei >> Chief Architect MariaDB >> and secur...@mariadb.org >> > > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
Re: [Maria-developers] Aggregate stored functions [MDEV-7773]
Hi Sergei, Sorry for the inconvenience , now you can comment on the document :) On Tue, Mar 22, 2016 at 1:25 PM, Sergei Golubchik wrote: > Hi, Varun! > > On Mar 22, Varun Gupta wrote: > > Hi Sergei , > > I have created a draft proposal and submitted to summerofcode website. > > I haven't written the project timeline yet. Please I would appreciate > > if you could go through it and leave comments so that I can make any > > necessary corrections. > > I've looked it through, but I cannot comment, because your document is > read-only. Open it for comments, please, then I'll leave some :) > > Regards, > Sergei > Chief Architect MariaDB > and secur...@mariadb.org > ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
[Maria-developers] Please review MDEV-9604 crash in Item::save_in_field with empty enum value
Hi Sergei,
It fixes the reported crash, and additionally
inconsistencies when comparing temporal columns to empty strings:
In some cases it returned rows, in other cases it returned no rows,
depending on:
- the engine
- the type of comparison arguments (columns vs literals).
- presence of an index
Now everything works in the same way.
Note, this additional problem is not 10.1 specific, it existed in 10.0.
But 10.0 and 10.1 worked differently in certain cases.
Thanks!
diff --git a/mysql-test/r/type_datetime.result b/mysql-test/r/type_datetime.result
index 155e953..16990c2 100644
--- a/mysql-test/r/type_datetime.result
+++ b/mysql-test/r/type_datetime.result
@@ -747,7 +747,7 @@ EXPLAIN EXTENDED SELECT * FROM t1 FORCE INDEX(attime) WHERE AtTime = '2010-02-22
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ref AtTime AtTime 6 const 1 100.00
Warnings:
-Note 1003 select `test`.`t1`.`Id` AS `Id`,`test`.`t1`.`AtTime` AS `AtTime` from `test`.`t1` FORCE INDEX (`attime`) where (`test`.`t1`.`AtTime` = '2010-02-22 18:40:07')
+Note 1003 select `test`.`t1`.`Id` AS `Id`,`test`.`t1`.`AtTime` AS `AtTime` from `test`.`t1` FORCE INDEX (`attime`) where (`test`.`t1`.`AtTime` = TIMESTAMP'2010-02-22 18:40:07')
DROP TABLE t1;
SET NAMES latin1;
#
@@ -963,21 +963,20 @@ a
2001-01-01 00:00:00
Warnings:
Warning 1292 Truncated incorrect datetime value: '2001-01-01 00:00:00x'
-Warning 1292 Truncated incorrect datetime value: '2001-01-01 00:00:00x'
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE LENGTH(a) != 20 AND a='2001-01-01 00:00:00x';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
Warning 1292 Truncated incorrect datetime value: '2001-01-01 00:00:00x'
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = '2001-01-01 00:00:00x')
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = TIMESTAMP'2001-01-01 00:00:00')
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE LENGTH(a)!=30+RAND() AND a='2001-01-01 00:00:00x';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
Warning 1292 Truncated incorrect datetime value: '2001-01-01 00:00:00x'
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = '2001-01-01 00:00:00x') and ((length(TIMESTAMP'2001-01-01 00:00:00')) <> (30 + rand(
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = TIMESTAMP'2001-01-01 00:00:00') and ((length(TIMESTAMP'2001-01-01 00:00:00')) <> (30 + rand(
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);;
INSERT INTO t1 VALUES ('2001-01-01 00:00:00'),('2001-01-01 00:00:01');
@@ -993,20 +992,20 @@ SELECT * FROM t1 WHERE LENGTH(a)=19 AND a=' 2001-01-01 00:00:00';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = ' 2001-01-01 00:00:00')
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = TIMESTAMP'2001-01-01 00:00:00')
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE LENGTH(a)=19+RAND() AND a=' 2001-01-01 00:00:00';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = ' 2001-01-01 00:00:00') and ((length(TIMESTAMP'2001-01-01 00:00:00')) = (19 + rand(
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = TIMESTAMP'2001-01-01 00:00:00') and ((length(TIMESTAMP'2001-01-01 00:00:00')) = (19 + rand(
EXPLAIN EXTENDED
SELECT * FROM t1 WHERE LENGTH(a)=30+RAND() AND a=' garbage ';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
Warning 1292 Incorrect datetime value: ' garbage '
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = ' garbage ') and (length(`test`.`t1`.`a`) = (30 + rand(
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where ((`test`.`t1`.`a` = TIMESTAMP'-00-00 00:00:00') and ((length(TIMESTAMP'-00-00 00:00:00')) = (30 + rand(
DROP TABLE t1;
CREATE TABLE t1 (a DATETIME);;
INSERT INTO t1 VALUES ('2001-01-01 00:00:00'),('2001-01-01 00:00:01');
@@ -1076,13 +1075,13 @@ SELECT * FROM t1 WHERE LENGTH(a)=19 AND a=TIME'00:00:00';
id select_type table type possible_keys key key_len ref rows filtered Extra
1 SIMPLE t1 ALL NULL NULL NULL NULL 2 100.00 Using where
Warnings:
-Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = TIME'00:00:00')
+Note 1003 select `test`.`t1`.`a` AS `a` from `test`.`t1` where (`test`.`t1`.`a` = TIMESTAMP
Re: [Maria-developers] Aggregate stored functions [MDEV-7773]
Hi, Varun! On Mar 22, Varun Gupta wrote: > Hi Sergei , > I have created a draft proposal and submitted to summerofcode website. > I haven't written the project timeline yet. Please I would appreciate > if you could go through it and leave comments so that I can make any > necessary corrections. I've looked it through, but I cannot comment, because your document is read-only. Open it for comments, please, then I'll leave some :) Regards, Sergei Chief Architect MariaDB and secur...@mariadb.org ___ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
