[
https://issues.apache.org/jira/browse/IGNITE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17832185#comment-17832185
]
Pavel Tupitsyn commented on IGNITE-21745:
-----------------------------------------
Merged to main: 71c320f0af1a41045a19381e4e859cf38726342a
> BinaryTuple stores BigDecimal inefficiently
> -------------------------------------------
>
> Key: IGNITE-21745
> URL: https://issues.apache.org/jira/browse/IGNITE-21745
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 3.0.0-beta1
> Reporter: Pavel Tupitsyn
> Assignee: Pavel Tupitsyn
> Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> * While we have varint logic for short/int/long, we don't have it for
> BigDecimal.
> * MAX_DECIMAL_SCALE = Short.MAX_VALUE (CatalogUtils)
> As a result, we can waste multiple kilobytes to store a very simple value.
> {code:java}
> BigDecimal value = new BigDecimal(1);
> BinaryTupleBuilder builder = new BinaryTupleBuilder(1);
> ByteBuffer bytes = builder.appendDecimal(value,
> Short.MAX_VALUE).build();
> assertEquals(13610, bytes.limit());
> {code}
> This is especially a problem with some SQL queries which return values with
> MAX_DECIMAL_SCALE as a result of calculations, for example:
> {code:sql}
> select (cast(_T0.VAL as decimal(20, 10)) / ?) as DECIMAL0 from
> PUBLIC.TBL_INT32 as _T0
> {code}
> Another problem - .NET client can't read those large-scale values because of
> built-in type limitation. Even though the actual value is just *1*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
