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
Decimal128::makeIndexKey() performance. For example, it stores
every 3 decimal
digits into 10 bits using relatively complex (computationally)
algorithm with
shifts and multiplications. Storing every digit in 4 bits will use
2 bits per 3
digits more but should save come CPU circles, I believe.
But that is the storage format of Decimal128 (DECFLOAT(34)).
No. It looks more like packed BCD. DECFLOAT uses a more complex
internals,
it is not BCD inside.
Decimal128 uses densely packed BCD (with some oddities to encode sign,
exponent and first digit).
It is not BCD and definitely not what uses
Decimal128::makeIndexKey().
See http://speleotrove.com/decimal/dbspec.html
and http://speleotrove.com/decimal/DPDecimal.html
Also, note, Decimal encodings is not directly sortable.
From that first link under 'coefficient continuation': "Each 10-bit
group represents three decimal digits, using Densely Packed Decimal
encoding." and at the footnote (and the top of your second link):
"Chen-Ho encoding is a lossless compression of three Binary Coded
Decimal digits into 10 bits using an algorithm which can be applied or
reversed using only simple Boolean operations".
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 the DOUBLE PRECISION format is
not suitable for BIGINT and NUMERIC/DECIMAL backed by BIGINT).
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel