On 10/02/2022 14:44, Dmitry Yemanov wrote: > 10.02.2022 20:18, Adriano dos Santos Fernandes wrote: >> >> 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. > > Looking at Statement::getRequest() I see it as dirty cheap, just a > matter of few allocations. >
Yes, but the impure space stores more allocations as execution is happening and this also serve as cache for later executions. So I think we have at least maintain a few ready instead of destroy all of them directly. And it seems we currently do not track later allocations stored in requests (for example vlu_string). And requests uses the statement pool. So maybe requests should have they own pool. In non-shared cache they could be sub-pool of the statement pool, but with shared cache they probably would need to be child of the attachment pool. >> 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. > > Getting rid of long-running but rare statements may be useful. If we > speak LRU, then the cached statement should be stamped when a new child > request is created. So we may defer "uncaching" of active request until > it's freed by user (if its statement weren't re-stamped in the > meantime). It's size should not be taken into account, as you say. > Yes. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
