On 10/02/2022 12:30, Vlad Khorsun wrote: > So, main benefit visible to end-user is to save prepare and check access > time, correct ?
Yes. > Also, good written apps (that re-uses prepared statements) > will not see much changes - at least until impl of shared metadata cache. > I consider ORM written applications as good ones. And I would not consider them good if they cache statements in the client requiring extra efforts to avoid locks in DDL changes in another connections. Also good written applications uses connection pools and will benefit from the cache. It's like saying the current sharing of JRD statements from procedures/functions/triggers inside the attachment has no value because it's not shared. So I do not agree with your points. > >> Also reuse of cached statements reduces memory consumption of individual >> uncached identical statements. > > I.e. when application uses more than one instance of the same > statement in > the same connection ? Hard to imagine, but everything possible... > ORMs tends to execute parameterized queries that is always executed again and again in the course of the application execution. This is very common pattern. > The main idea is to allow to disable user cache but not system cache. > Are you going to move IRQ_REQUESTS and DYN_REQUESTS into such system cache, > or am I too optimistic ? > As I said in another answer, I consider this a different topic. >> If they are not, them when roles are different than one present in >> cached statement, a verifyAccess would need to be called on the >> statement get from the cache before it's usage is allowed. > > I ask because such restrictions could make stmt cache less useful. > > For example, we could keep list of already verified set of credentials > (user name + roles list) with cached stmt to not include it into key. > Yes, this is good. > I want to clarify - what happens when app prepares (or execute) two > identical stmts ? First instance could be taken from cache, ok. What > happens with second instance ? > First statement is prepared like before (parse, DSQL passes, GEN, JRD compile, JRD passes, DSQL messages) and then inserted into the cache. Will then create DSQL request with dsqlStatement->createRequest(). Second prepare will see the statement key in the cache and get DsqlStatement from it, check access and do dsqlStatement->createRequest(). Statement cache is basically a map<key, RefPtr<DsqlStatement>>. DSqlStatement has the (Jrd)Statement inside it. So cached statements avoid all DSQL and JRD compilation passes. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
