You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Joel Lang (JIRA)" <ji...@apache.org> on 2018/05/03 02:18:00 UTC

[jira] [Commented] (IGNITE-8385) SQL: Allow variable-length values in index leafs

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