[
https://issues.apache.org/jira/browse/CASSANDRA-20100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17902755#comment-17902755
]
Michael Marshall commented on CASSANDRA-20100:
----------------------------------------------
Is the fundamental problem the truncated types here?
{{{}> inet{}}}, {{{}bigint{}}}, {{{}varint{}}}, and {{decimal}}
If so, I have a clarifying question: which bigint are we talking about here? I
am not surprised that inet, varint, and decimal had issues because those types
are truncated, but I am pretty sure the `bigint` cql type maps to Java's `Long`
type, which does not get truncated.
> Query construction is broken for SAI indexes on reversed types with
> fixed-length encodings
> ------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-20100
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20100
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Feature/2i Index, Feature/SAI
> Reporter: Caleb Rackliffe
> Assignee: Caleb Rackliffe
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Attachments: ci_summary.html
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> SAI indexes values in byte-comparable form, both in the in-memory trie that
> sits alongside the Memtable, and in the on-disk SSTable-adjacent indexes. In
> most cases, this means literally using {{asComparableBytes()}} from the type
> of the indexed column. There are, however, a few types that use a custom
> byte-comparable form, namely {{inet}}, {{bigint}}, {{varint}}, and
> {{decimal}}, to make sure we're dealing with a fixed-length piece of data for
> the numeric (balanced tree) index.
> If we index one of these types as a reversed clustering key, however, we
> don't write terms as reversed comparable bytes, and this breaks some
> assumptions during query construction and post-filtering, where we generally
> assume that {{asComparableBytes()}} will reverse terms before they are
> indexed. We can make a short-term fix here without changing anything about
> the on-disk format by making sure we interpret these special types as being
> non-reversed (i.e. through the lens of their base types).
> In the longer term, it might make sense to standardize on indexing everything
> in a non-reversed fashion in the index itself, although this might push some
> complexity into post-filtering, where we are going to have to filter data
> coming out of the normal read path anyway.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
