On 2/28/22 20:30, Adriano dos Santos Fernandes wrote:
On 28/02/2022 13:18, Alex Peshkoff via Firebird-devel wrote:
I suppose it's with mentoned 2Mb cache.
Yes. But it's the same even with 100K as the test uses very few and
small statements.
Taking into an account that bigmost was 21k there are really few
statements :)
Did you try with smaller cache size?
One more question. Suppose some statement remains in a cache for very
long time cause it's reused again and again. That's fine - but with DB
grow optimal plan can change. Is it solved somehow? Suppose in first
implementation not,
Correct.
And it's a problem also now when application holds prepared statement
manually, but that probably is not going to be changed.
Yes, it's out of scope.
but are there plans to solve it?
I think there are two possible ways:
- Timeout of cached statement (counting from its first appearance in
cache, not last usage)
Yes, re-preparing all statements once per relatively big timeout should
not cause visible performance problem.
- When engine detects a condition which could change a plan, it may ask
cache for invalidation.
At the first glance that's changing index active/inactive and in the
future bulk insert. That's first things that come to my mind.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
