[ https://issues.apache.org/jira/browse/IGNITE-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16461844#comment-16461844 ]
Joel Lang commented on IGNITE-8385: ----------------------------------- I did not realize there were situations where the actual indexed value would not be stored in the index itself. This might explain a great deal of the performance issue I had when using random UUID string indexes with a HDD. While the string contains a UUID that is not an actual requirement, so I can't change the data type to use the java UUID class, yet. After looking through the code I see CacheConfiguration has the max inline size option that I'm going to try raising to 36 to fit a complete UUID string. > SQL: Allow variable-length values in index leafs > ------------------------------------------------ > > Key: IGNITE-8385 > URL: https://issues.apache.org/jira/browse/IGNITE-8385 > Project: Ignite > Issue Type: Task > Components: sql > Affects Versions: 2.4 > Reporter: Vladimir Ozerov > Priority: Major > Labels: iep-19, performance > Fix For: 2.6 > > > Currently we have a restriction that every entry inside a BTree leaf should > be of fixed size. This restriction is artificial and prevents efficient index > usage because we have to choose so-called {{inline size}} for every index > manually. This is OK for fixed-size numeric types. But this could be a > problem for varlen types such as {{VARCHAR}} because in some cases we cannot > fit the whole value and have to fallback to data page lookup. In other cases > we may pick too pessimistic inline size value and index space would be > wasted. > What we need to do is to allow arbitrary item size in index pages. In this > case we would be able to inline all necessary values into index pages in most > cases. > Please pay attention that we may still met page overflow in case too long > data types are used. To mitigate this we should: > 1) Implement IGNITE-6055 first so that we can distinguish between limited and > unlimited data types. > 2) Unlimited data types should be inlined only partially > 3) We need to have special handling for too long rows (probably just re-use > existing logic with minimal adjustments) -- This message was sent by Atlassian JIRA (v7.6.3#76005)