On 2/8/22 16:36, Adriano dos Santos Fernandes wrote:
Hi!
I have refactored DSQL statements/requests (continued worked of many
time ago) to separate shared (statement) and specific (request) parts.
It seems this ground work for compiled statement cache is complete and I
have even did a (very very) initial version of a compiled statement
cache working.
Now I think it's better to discuss its semantics.
First what should be the statement key in the cache?
I've peek these:
- statement text
- clientDialect
- isInternalRequest
- current client charset (as external engines may change it)
- active roles
Do you see any thing more?
Even if you missed something adding an item later should not be too
awful problem.
Then there is when statements should go out of cache?
I see three approaches:
- 1. Timeout after its put in the cache, updated when it is get from it
- 2. LRU based on memory consumption and max cache size
- 3. Both 1. and 2.
I think we can start with 1.
I like 2 better - we have much less chances to go OOM with it.
Should it be enabled by default?
I think yes. And it may have per database configuration of the timeout
value.
Or cache size value...
Cache invalidation:
Cached (and unused) statements should not lock objects preventing DDL
changes.
Assuming that cached statements never lock anything exclusively (there
should be bug if that happens), then when someone tries to lock
something exclusively it should ask caches to release the statements
having that objects.
Or, I think it's completely ok for an initial implementation, any try to
exclusively lock an object may ask caches for complete invalidation.
Agreed - that's ok, for first time definitely.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
