08.02.2022 15: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.
First, please, describe - what goals\benefits of this cache ? Especially,
taking into account current per-attachment metadata.
Now I think it's better to discuss its semantics.
First what should be the statement key in the cache?
All what affects statement compilation process, at least.
I've peek these:
- statement text
- clientDialect
- isInternalRequest
Why it is important ? Do we have internal DSQL requests now ?
Is it makes sense to have two caches - for internal and for user
statements ?
- current client charset (as external engines may change it)
- active roles
If\when shared metadata will be implemented - will it be possible to
use cached compiled statement created in one attachment to use by another
attachment ? If yes, does it means that another attachment should use same
client charset and active roles to be able to use cached compiled statement ?
Do you see any thing more?
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.
For me 2 is a must, 1 good to have but less important.
Should it be enabled by default?
I think yes.
Yes for internal requests. Not sure about user requests.
> And it may have per database configuration of the timeout
> value.
Sure.
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.
Enough for start, IMHO.
And you not explained cache usage - when and how cached statement should be
used.
Regards,
Vlad
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
