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 is storage
and performance difference between idx_decimal and idx_bcd?
But I wonder - what to do with existing databases? Rebuilding affected
indexes is enough - but such database becomes unusable for previous
versions of engine. Normally we should increase ODS minor. But last time
when it was done in FB3 it gave serious negative feedback. Next,
upgrading ODS requires gbak/restore cycle, which is problematic with big
database.
I'd consider committing the solution into v5 only. In v4, index lookups
should work, although suboptimal for very big numbers. As for index
ordering, we may document the issue and leave it up to users. I doubt
those who already utilized INT128 do really use such big numbers in
production. If they do, they may add a +0 hint to work slower but safe.
Or we may add a (temporary) configuration switch that disables the index
ordering for INT128. Given that we expect v5 to be released soon, it
could be acceptable as a temporary measure.
Perhaps we could invent something clever like converting an ORDER'ed
select into UNION ALL with the first partition (<= 10^34) ordered by
index and the second one sorted naturally, but it looks like too much
effort for a temporary solution.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
