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
NUMERIC/DECIMA
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 b
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 conv
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 erro
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
long
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 b
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 w
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 int
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 conv
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
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)
algo
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 id
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
Decimal
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 examp
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 int
15 matches
Mail list logo
