[
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)
