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