Re: [Firebird-devel] Compiled statement cache
On 03/03/2022 14:19, Alex Peshkoff via Firebird-devel wrote: > 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? > No, only with it disabled. I still have some problems to detect statements size with more precision. > At the first glance that's changing index active/inactive This should be already invalidating cache, as it's a DDL statement. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Compiled statement cache
03.03.2022 20:19, Alex Peshkoff via Firebird-devel wrote: 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. Better it should be "re-optimizing" (just CMP_post_rse) rather than "re-preparing". The problem is that the optimizer uses the same request pool and all its allocations are "delete-by-pool", so re-optimization is gonna to become a memory leak. Perhaps we'll need to add an explicit request's child pool for optimization purposes which can be re-created during re-optimization. - 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. It's more complex than that, but I think this is a 2nd priority task and somewhat later I'll jump in to help with the optimizer part. Dmitry Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
Re: [Firebird-devel] Compiled statement cache
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
[Firebird-devel] Roadmap, Planning Board, version of 4.0 snapshots
Hi All, 3.0.9 already released, please update the Roadmap page. 5.0 Alpha not released in January, please update the Planning Board page. 4.0.1 already released but the snapshot's version still 4.0.1. Thank you! :-) Gabor Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
