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? 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. Should it be enabled by default? I think yes. And it may have per database configuration of the timeout 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. Comments? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel