29.11.2011 12:35, Vlad Khorsun wrote:
While i agree with you about SUBSTRING, i think the much better solution
will be to allow to index COMPUTED BY columns. It allows to not compare
potentially complex expressions at optimize time and to not write exactly
same expressions in every query
29.11.2011 9:48, Dmitry Yemanov wrote:
29.11.2011 12:35, Vlad Khorsun wrote:
While i agree with you about SUBSTRING, i think the much better solution
will be to allow to index COMPUTED BY columns. It allows to not compare
potentially complex expressions at optimize time and to not write
On Tue, 29 Nov 2011 10:07:29 +0100, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
Perhaps, better approach would be silently cut long index keys to
implementation limit.
This way we don't loose anything, just increase number of real
comparsions with negative
result during selects.
On 11/29/11 13:37, Adriano dos Santos Fernandes wrote:
On 29/11/2011 05:49, Alex Peshkoff wrote:
May be we can think about builting function like index_expr. That's just
raw idea, but may be something like
INDEX_EXPR(ALIAS.indexName)
is better than
This is up to the user to create a
On 29-11-2011 05:56, Dmitry Yemanov wrote:
28.11.2011 23:08, Adriano dos Santos Fernandes wrote:
No. It happens with large varchar column. So it turns back to my
question: can we describe a column with a length we know will fit and
will have no side effects other than just being described
Adriano,
select char_length( SUBSTRING(col1 from 1 for 20)) from tbl_test
returns
20 so I was expecting index to work.
workaround
CREATE INDEX IDX1 ON tbl_test COMPUTED BY (CAST(SUBSTRING(col1
from 1
for 20) as varchar(20)))
This issue depends if we're allowed to change
On 28/11/2011 16:22, Leyne, Sean wrote:
Adriano,
select char_length( SUBSTRING(col1 from 1 for 20)) from tbl_test
returns
20 so I was expecting index to work.
workaround
CREATE INDEX IDX1 ON tbl_test COMPUTED BY (CAST(SUBSTRING(col1
from 1
for 20) as varchar(20)))
This issue
