[ https://issues.apache.org/jira/browse/IGNITE-21745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Tupitsyn updated IGNITE-21745: ------------------------------------ Description: * 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*. was: * 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 values with such a large scale because of built-in type limitation. Even though the value is just *1*. > 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: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > * 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)