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