> From: Dmitry Kuzmenko:
> > 3) Increase max index key size from 255 to 64K.
>
> cool! But.... Maybe it is much easier to do "silent key trimming" when key size is bigger
> than X bytes (for example 64 or 84)?
> I mean, with B-tree index we can search =, > or <. I don't know applications that
> can differ strings longer than ~80 characters. I think indexing the whole 2K or even 64K is
> completely useless.

If I remember correctly, older IB versions did not enforce limit on index key length
when creating index, but at runtime. Because index keys are compressed,
it was possible to store/index longer strings than in current IB versions.
The problem was that
- you could get error message even when inserting string that fits to column
(in current IB you either can index short columns and you are guaranteed
to not have problems with indexed strings, or you can't index too long columns at all)
- error messages was not consistent from users point of view
(it was possible to insert long string that compressed well in index,
and then it was not possible to insert much shorter string just because
it dit not compress that well)

"silent key trimming" should not cause big problems
when using such index for search (see "Re: Strange performance result" thread at Mers),
i.e. you will get correct results without any change to current IB engine
(perhaps except LIKE and STARTING).

ORDER BY can cause some problems though. You will either get wrong order
for long (trimmed) strings, or indexing long strings will be slower
(because it will require to look at actual, non-trimmed data for adjacent
index entries)

But increasing max index key size from 255 to 64K
seems like proper/long term solution to me.
Does it have any serious disadvantages ?

Ivan
prenosil@...