„The main reason why this "removal of trailing partial contraction" was
done is to achieve behavior "consistent" with search/evaluation in other
software (like text editors etc.), so (for example) STARTING WITH "C" or
LIKE "C%" will return rows starting with "C" or "CH".
This behavior itself is questionable (but more about that later)
„
I try to understand the issue but meybe simpler description is required.
When i use WIN1250 collate PXW_PLK (my Polish language)
Then engine threat all „ch” as single letter in the index?
And i cannot find looking by only „c” without „h” with index lookup?
If yes how engine decide that this is „ch” or „c” and „h” in words?
If i write:
„chmura” it can be ok
But if i write (i write upper letter to show the problem):
„cHandle” which is not „ch” at all?
Is my understanding ok or i misunderstand description of performance
degradation?
regards,
Karol Bieniaszewski
Od: Pavel Cisar
Wysłano: czwartek, 4 listopada 2021 15:14
Do: firebird-devel@lists.sourceforge.net
Temat: Re: [Firebird-devel] RFC: Fix for issue 6915
Mama mia, here we go again.
I have no intention to get sucked even deeper into this endless
discussion. I'm fighting covid right now and really don't feel fit for
it. In fact, I personally don't care HOW this will be fixed, as long as
it WOULD be fixed in some timely manner, which is obviously and sadly
not going to happen.
If it would be on me, the best fix would be fixing physical storage
inefficiency for UTF8 data. The "contraction" problem is in Firebird for
long time, and it wasn't real performance killer until everyone keeps
with NARROW charsets (proven by tests). It's the UTF8 storage
inefficiency that blows this out of proportions (also proven by tests).
Everyone knows that this is the real problem that hurts the performance
in general, and there was a push from users to solve that for many
years. There was even new RLE code from ElectLabs to solve it, and
although it was not accepted - as far as I remember - a solution was
promised by project. Six years later, we still got nothing (I and see no
such thing on v5.0 roadmap so go figure).
Now this failed promise bitten us back as another unhappy Firebird user
(one from big Czech software houses that uses Firebird from day one)
that needs to switch hundreds of databases of its big international
customers from codepages to UTF8 in Q1/2 next year got stuck as
extensive testing revealed serious performance issues after switch to
UTF8 ("contraction" issue is just the biggest performance loss spike, so
they bring it to our attention). They are even willing to pay to get it
solved, but as months pass, it's more and more obvious that they will
eventually end as dead in the water (no solution in due time). Guess
what? As they are under pressure themselves to do the switch, they will
have to start move away from Firebird for important big projects (no
kidding). They will certainly keep it for low end as it makes sense, but
anyway.
Maybe I'm just getting old and worn by mounting waste of time and
effort, but it appears like the project is slowly but surely losing its
drive and spirit over years, as it more and more feels that we're
running to stand still.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
