On 10/02/2022 13:13, Dmitry Yemanov wrote:
> 08.02.2022 16:36, Adriano dos Santos Fernandes wrote:
>>
>> 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)
> 
> Cannot the UTF8-translated SQL text (which is currently inside
> Statement::sqlText) be the key, to avoid dependency on the charset? I
> don't think that semantically different statements may have the same
> UTF8 representation. However, it would make sense to have a single
> cached statement for the same statement executed from different client
> charsets.
> 

Answered in another topic.


>> 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'd start with 2.

Ok.


> How are you going to calculate the memory consumption?
> Size of the statement pool + impureSize?
> 

I don't think the impureSize should be taken. It's related to request
executions.

We should have better strategy for request cache inside the statement.
If they are cheap to create, it would make no sense to never destroy
them like now.

I would calculate size of statement as sum of DSQL statement pool + JRD
statement pool after it is prepared.

Please note that requests (both DSQL and JRD) are also created from the
statement pools.

But if there are active requests, I think the statement should not even
be considered to be taken out of cache. It's necessary in this case, so
in reality it does not use cache space.

So I think cache size (to remove least recent used) should not consider
active (necessary) statements.


Adriano


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to