On 2/15/22 18: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 multipl
21.02.2022 20:05, Alex Peshkoff via Firebird-devel wrote:
This is possible way to fix a bug:
https://github.com/FirebirdSQL/firebird/commit/7dd832f32e9669bcb3007dc675b3ee7cca6f6b7d
New type of indexes is added and it works fine.
I didn't look at the patch deeply yet, so the question: what i
On 2/16/22 13:49, Alex Peshkoff via Firebird-devel wrote:
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 no
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.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 (computa
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 mul
Dmitry Yemanov wrote 15.02.2022 18:14:
Your schema upgrade may change keys from INT to BIGINT (when tables grow more
than expected) or, more usually -- NUMERIC(N, 3) is changed to NUMERIC(N, 5) for
quantities, or NUMERIC(12, N) is changed to NUMERIC(18, N), etc. And it should
be applied to prod
15.02.2022 18:37, Kjell Rilbe wrote:
With respect, since I'm not in the dev team, I fail to see it as an
important feature to avoid index rebuild when changing between integer
and numeric column types:
1. Changing between such types must be pretty rare, at least on
production databases. Dur
Den 2022-02-15 kl. 16:10, skrev Vlad Khorsun:
15.02.2022 15:20, Dmitry Yemanov wrote:
...
I can think of two ways to proceed:
1) Keep rebuilding the index every time the type is changed. Cast all
column values into the new format before storing keys into the index.
Forget about being scale-
15.02.2022 13:28, Dmitry Yemanov wrote:
All,
Historically, we store most numerics as double precision inside index keys. It makes stored keys independent of the declared scale
and allows both prefix and suffix compression. However, int64 keys (BIGINT and largish NUMERICs/DECIMALs) do not fit th
15.02.2022 15:20, Dmitry Yemanov wrote:
...
I can think of two ways to proceed:
1) Keep rebuilding the index every time the type is changed. Cast all column values into the new format before storing keys into the
index. Forget about being scale-independent, pick the scale from the latest tabl
15.02.2022 14:41, Dimitry Sibiryakov wrote:
Is "stored keys independent of the declared scale" a really useful
and used feature?
That's a separate but also good question. Double precision keys allow
independence of both precision (within its range) and scale. AFAIU, the
idea was to allow ch
On 15/02/2022 08:28, Dmitry Yemanov wrote:
>
> Any other comments?
>
Would not it be possible to use some form of varint encoding (VLQ) there?
Adriano
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Dmitry Yemanov wrote 15.02.2022 12:28:
Does anyone think we should investigate this possibility more closely? Any other
comments?
Is "stored keys independent of the declared scale" a really useful and used
feature?
If we prohibit that, the index key can be a plain integer without rounding
28 matches
Mail list logo
