Huge +1 with Ilya
I check your pr, this looks like stub : Pattern . compile( " \\ w+ \\ (( \\
d+) \\ ) " );
* Do we have some normalization before it ? varchar(whitespace + N) looks like
not matching.
* Can we obtain this info not from regexp ?
>Hello!
>
>I can see where you are getting at
Hello!
I can see where you are getting at but, as far as my experience tells me,
64 is already too large for the average use case. It will also start to
drag on the performance since you don't have too many entries in one page
anymore, and your tree starts to grow up, not to mention more i/o.
I
Hi guys,
Thank you for your feedback.
Current calculation of the default size is not completely correct. If it
meets a field of the variable length (such as byte array or string) it just
stops any attempt to make index size more reasonable and uses
IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT as its
Hi,
In my mind, the inline size 64 will be able to significant grow of storage
size.
It can be difficult to understand by users.
Earlier I remember we panned to replace inline value to hash code in the
case where size of value more than inline size.
It will help to comparison of "==", "!=", but
>Hi guys,
Evgeniy, hola!
>
>Currently if a varlength type (such as String or byte[]) is encountered in
>the composite index inline size just defaults to 10, which is almost always
>not enough. I am going to change this and implement following changes:
>
>1) For a column of the variable length
Hi guys,
Currently if a varlength type (such as String or byte[]) is encountered in
the composite index inline size just defaults to 10, which is almost always
not enough. I am going to change this and implement following changes:
1) For a column of the variable length keep using 10 as the
