Stanislav,

> I think the most compatibility impact will be on the in-memory caches with 
> SQL and without explicitly specified inline sizes.

I don't think that this is `true` compatibility issue. But I think we
should at least mentioned it on our documentation pages and in the
release notes. So, I'm +1 to proceed with the merge.

Should we include the issue into 2.10 release?

On Fri, 8 Jan 2021 at 16:50, Stanislav Lukyanov <stanlukya...@gmail.com> wrote:
>
> Hi Igniters,
>
> I'd like to discuss the change implemented by Evgeniy Rudenko in the ticket 
> https://issues.apache.org/jira/browse/IGNITE-13364.
> I see that the fix is ready for review and merging, and I'm interested in it 
> so I'd like to pick it up on the last mile.
> I also wanted to bring community's attention to it before the merge as it 
> changes the default behavior.
>
> The patch changes how SQL index inline size is calculated.
>
> Specifically:
>
> 1. When inline size is calculated for a variable-sized field, a constant 10 
> (configurable via IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE) is added to the 
> calculated size instead of setting the entire calculation result to 10.
> For example, consider the following cases
>
> Index (int, int, string)
> Before the change: inline size = 10
> After the change: inline size = 5 + 5 + 10 = 20
>
> Index (long, long, long, long,  string)
> Before the change: inline size = 10
> After the change: inline size = 9 + 9 + 9 + 9 + 10 = 46
>
> 2. If there is a VARCHAR_FIXED, e.g. VARCHAR(5), then instead of the default 
> IGNITE_VARIABLE_TYPE_DEFAULT_INDEX_SIZE Ignite will use the value provided in 
> the calculation
>
> 3. If the calculated size exceeds IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT=64, 
> it will be truncated to 64.
>
> All of this only affects calculated inline sizes of new indexes.
> Existing indexes should not be affected.
> Indexes with explicitly specified inline size should not be affected.
>
> I think the most compatibility impact will be on the in-memory caches with 
> SQL and without explicitly specified inline sizes.
> After the upgrade these caches may slightly increase in size (because the 
> inline is likely to become bigger) while SQL is also likely to become faster.
>
> Please comment.
> If there are no concerns, I'll proceed with finding a committer to review and 
> merge the fix at the end of the next week.
>
> Thanks,
> Stan

Reply via email to