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. During app development, yes, sure, but at that
stage the data is probably small or non existent, so rebuild won't
matter anyway.
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 production. And a
longish index rebuild will block all other DML on that table.
Maybe not so common, usually not recommended, etc -- but surely possible.
2. It already doesn't work and nobody has really complained, correct?
Correct, but it does not mean we cannot do something better. Not doing
something is always faster than doing something ;-) so why not?
3. Changing data type of an indexed column is an operation where you do
expect a non-negligible impact, i.e. you expect the DB engine to have to
do "some work".
Users of other DBMS usually expect to see "some work" while adding a
column to a table with 10^9 rows (or dropping a column there). Firebird
does it almost instantly. So expectations are somewhat subjective and
may be out of sync with realities...
So, I'd vote for a solution that drops the ambition to avoid index
rebuilds, and instead focuses only on index size and index performance.
We can (and I believe we should) do both -- improve index
size/performance and avoid index rebuilds if possible.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
