On 2/16/22 12:54, Dmitry Yemanov wrote:
16.02.2022 12:19, Mark Rotteveel wrote:
However, that was not my main point. My main point was that it sounds
like an index format that was created for supporting DECFLOAT(34),
and that it is not suitable for the full range of INT128 and
16.02.2022 11:19, Mark Rotteveel wrote:
On 2022-02-16 09:56, Vlad Khorsun wrote:
16.02.2022 10:35, Mark Rotteveel wrote:
On 2022-02-15 20:08, Vlad Khorsun wrote:
15.02.2022 20:32, Mark Rotteveel wrote:
On 2022-02-15 16:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of
16.02.2022 12:54, Dmitry Yemanov wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to add a
runtime check that rejects key creation for INT128 values longer than 34
decimal digits.
Thinking twice, an overflow error should already been raised when a
longish INT128 is
16.02.2022 11:45, Alex Peshkoff via Firebird-devel wrote:
On 2/15/22 18:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal
Appears to be good idea.
and look how to improve
Decimal128::makeIndexKey() performance. For example, it stores every 3 decimal
digits
On 2/16/22 12:45, Alex Peshkoff via Firebird-devel wrote:
To be precise - 9 digits into ULONG. No shifts (BTW what a problem
with them, CPUs have appropriate fast support since first pentium or
even more). There is one division of small integer (range from 0 to
33). It can be easily replaced
On 2/16/22 13:28, Dmitry Yemanov wrote:
16.02.2022 13:24, Alex Peshkoff via Firebird-devel wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to
add a runtime check that rejects key creation for INT128 values
longer than 34 decimal digits.
Thinking twice, an overflow
16.02.2022 10:35, Mark Rotteveel wrote:
On 2022-02-15 20:08, Vlad Khorsun wrote:
15.02.2022 20:32, Mark Rotteveel wrote:
On 2022-02-15 16:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal and look
how to improve
Decimal128::makeIndexKey() performance. For
On 2022-02-16 09:56, Vlad Khorsun wrote:
16.02.2022 10:35, Mark Rotteveel wrote:
On 2022-02-15 20:08, Vlad Khorsun wrote:
15.02.2022 20:32, Mark Rotteveel wrote:
On 2022-02-15 16:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal and look
how to improve
On 2/15/22 18:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal
Appears to be good idea.
and look how to improve
Decimal128::makeIndexKey() performance. For example, it stores every 3
decimal
digits into 10 bits using relatively complex (computationally)
On 2/16/22 12:59, Dmitry Yemanov wrote:
16.02.2022 12:54, Dmitry Yemanov wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to add
a runtime check that rejects key creation for INT128 values longer
than 34 decimal digits.
Thinking twice, an overflow error should already
16.02.2022 13:28, Dmitry Yemanov wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to
add a runtime check that rejects key creation for INT128 values
longer than 34 decimal digits.
Thinking twice, an overflow error should already been raised when a
longish INT128 is
On 2/16/22 13:34, Dmitry Yemanov wrote:
16.02.2022 13:28, Dmitry Yemanov wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to
add a runtime check that rejects key creation for INT128 values
longer than 34 decimal digits.
Thinking twice, an overflow error should already
On 2022-02-15 20:08, Vlad Khorsun wrote:
15.02.2022 20:32, Mark Rotteveel wrote:
On 2022-02-15 16:20, Vlad Khorsun wrote:
I'd vote to remove idx_numeric2 in favour of idx_decimal and look
how to improve
Decimal128::makeIndexKey() performance. For example, it stores every
3 decimal
digits
16.02.2022 12:19, Mark Rotteveel wrote:
However, that was not my main point. My main point was that it sounds
like an index format that was created for supporting DECFLOAT(34), and
that it is not suitable for the full range of INT128 and NUMERIC/DECIMAL
backed by INT128 (for the same reasons
16.02.2022 13:24, Alex Peshkoff via Firebird-devel wrote:
It looks so. Unless we miss something (Alex?), perhaps we need to add
a runtime check that rejects key creation for INT128 values longer
than 34 decimal digits.
Thinking twice, an overflow error should already been raised when a
15 matches
Mail list logo
