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