[
https://issues.apache.org/jira/browse/IGNITE-8385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462846#comment-16462846
]
Joel Lang commented on IGNITE-8385:
-----------------------------------
I spent some time looking at the source code and debugging to figure out how
things worked.
A surprising issue I found is that if the indexed field is a timestamp (16
bytes), and the cache key is a string, then inline comparison doesn't happen at
all. The computeInlineSize() method defaults to using
IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT which is 10. A data page lookup always
happens then because partial comparison isn't possible. [~vozerov] could you
confirm if this is intended behavior? I did not see any documentation about it
and how critical the inline size seems to be to performance here.
I'm fixing this by setting inlineSize on the QuerySqlField annotation to 17 for
the timestamp field, which also makes it ignore the type of the _KEY column.
I also see that partial string comparison can still happen inline even if the
whole string wouldn't fit into the inline size. That's good then.
> 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)
