Benedict commented on CASSANDRA-15232:

Thanks for the insight [~blerer] :)

[~Override] thanks for the patch.  It looks good.  I have only one concern, 
around division, namely how the scale calculation is now potentially costlier 
than the division itself.  This may not be a huge problem, but it is a shame, 
and it would be nice to mitigate it.

The costliest part is calculating the first digit of each operand - I 
personally think it would be acceptable to ignore this part of Postgres' 
calculation to avoid introducing the extra garbage and computation.

However, if we do want to retain this part, we should at least avoid performing 
it when we know it is of no value - i.e. when the scale of the result is such 
that we must ignore the contribution of these digits, because we know for sure 
the scale will be overridden by min or max; or when the scales are equal, we 
can perform a comparison of the two decimals themselves without extracting the 
first digit.

We can _probably_ also make this computation less costly by using 
{{BigDecimal.scaleByPowerOfTen}}, if we keep it.

What do you think?

> Arithmetic operators over decimal truncate results
> --------------------------------------------------
>                 Key: CASSANDRA-15232
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-15232
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL/Semantics
>            Reporter: Benedict
>            Assignee: Liudmila Kornilova
>            Priority: Normal
>              Labels: pull-request-available
>             Fix For: 4.0
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
> The decimal operators hard-code a 128 bit precision for their computations.  
> Probably a precision needs to be configured or decided somehow, but it’s not 
> clear why 128bit was chosen.  Particularly for multiplication and addition, 
> it’s very unclear why we truncate, which is different to our behaviour for 
> e.g. sum() aggregates.  Probably for division we should also ensure that we 
> do not reduce the precision of the two operands.  A minimum of decimal128 
> seems reasonable, but a maximum does not.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to