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
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
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
On 10/02/2022 14:13, Dimitry Sibiryakov wrote:
> Dmitry Yemanov wrote 10.02.2022 18:07:
>>> But as I said and Vlad also said, we can remove roles from key and
>>> verify (with verification cache) after get statement from cache. This
>>> would be better.
>>
>> Yes, this gets my vote too.
>
> On
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
Dmitry Yemanov wrote 10.02.2022 18:07:
But as I said and Vlad also said, we can remove roles from key and
verify (with verification cache) after get statement from cache. This
would be better.
Yes, this gets my vote too.
On the other hand ACL verification used to be a known bottleneck in
On 10/02/2022 13:34, Dimitry Sibiryakov wrote:
> Dmitry Yemanov wrote 10.02.2022 17:28:
>>> Only if such translation is made right. Remember charset introducers.
>>
>> They're a problem, but it may only cause a cache miss, not a false
>> match, right?
>
> Yes, they can only cause miss but I'm
On 10/02/2022 13:28, Dmitry Yemanov wrote:
>
> In the ideal world, maybe. But this is *much* more complicated than it
> seems at the first glance.
>
I'd even go further and say we should not slow down things to catch this.
Adriano
Firebird-Devel mailing list, web interface at
10.02.2022 19:54, Adriano dos Santos Fernandes wrote:
I come with this requirement because verifyAccess is currently part of
compilation.
But as I said and Vlad also said, we can remove roles from key and
verify (with verification cache) after get statement from cache. This
would be better.
On 10/02/2022 13:21, Dimitry Sibiryakov wrote:
> Dmitry Yemanov wrote 10.02.2022 17:13:
>> 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
On 10/02/2022 13:20, Dmitry Yemanov wrote:
> 10.02.2022 16:01, Adriano dos Santos Fernandes wrote:
>>
>> (Jrd)Statement is reused - new jrd_req are get from same statement.
>
> IIRC, the existing cache of internal requests preserves jrd_req's. Am I
> right that after the jrd_req->Statement
On 10/02/2022 13:20, Dmitry Yemanov wrote:
> 10.02.2022 16:01, Adriano dos Santos Fernandes wrote:
>>
>> (Jrd)Statement is reused - new jrd_req are get from same statement.
>
> IIRC, the existing cache of internal requests preserves jrd_req's. Am I
> right that after the jrd_req->Statement
On 10/02/2022 12:43, Dmitry Yemanov wrote:
> 10.02.2022 15:57, Adriano dos Santos Fernandes wrote:
>>
>>>
>>> If we need to take roles into an account - only for attachment with same
>>> USER.
>>
>> Even without shared cache, user can change its roles with SET ROLES and
>> new prepared statements
Alex Peshkoff via Firebird-devel wrote 10.02.2022 17:35:
If we see solid effect from new cache - certainloy, it will be worth to make it
better prepare search key. I.e. let's start from something simple and see does
it make sense.
That's why I suggested to ask kdv for stats: to prevent a
On 2/10/22 19:21, Dimitry Sibiryakov wrote:
Dmitry Yemanov wrote 10.02.2022 17:13:
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
Dmitry Yemanov wrote 10.02.2022 17:28:
Only if such translation is made right. Remember charset introducers.
They're a problem, but it may only cause a cache miss, not a false match, right?
Yes, they can only cause miss but I'm not sure about literals as whole. Are
they stored in
10.02.2022 19:21, Dimitry Sibiryakov wrote:
Only if such translation is made right. Remember charset introducers.
They're a problem, but it may only cause a cache miss, not a false
match, right?
But apparently to transform the query before using it as a cache key
is a right idea. Two
Dmitry Yemanov wrote 10.02.2022 17:13:
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
10.02.2022 16:01, Adriano dos Santos Fernandes wrote:
(Jrd)Statement is reused - new jrd_req are get from same statement.
IIRC, the existing cache of internal requests preserves jrd_req's. Am I
right that after the jrd_req->Statement refactoring the cost of creation
of new jrd_req is
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
Dmitry Yemanov wrote 10.02.2022 16:43:
I'm not sure I get why security credentials should affect the cache at all. From
the runtime POV, all BLR/SQL operations (current_user/current_role/rdb$*_roles)
are redirected to Attachment, AFAIK we don't store anything role-specific inside
the statement
10.02.2022 17:35, Dimitry Sibiryakov wrote:
Vlad Khorsun wrote 10.02.2022 16:30:
More, I already implemented simple cache of prepared statements near 5 years
ago and I know when it is useful :) It was not ported into Firebird because of
limited usage and its simplicity. But customer which
10.02.2022 15:57, Adriano dos Santos Fernandes wrote:
If we need to take roles into an account - only for attachment with same
USER.
Even without shared cache, user can change its roles with SET ROLES and
new prepared statements should work as before even when they were
previously cached
Vlad Khorsun wrote 10.02.2022 16:30:
More, I already implemented simple cache of prepared statements near 5 years
ago and I know when it is useful :) It was not ported into Firebird because of
limited usage and its simplicity. But customer which uses it, was very happy.
Isn't it inside of
10.02.2022 14:56, Adriano dos Santos Fernandes wrote:
On 10/02/2022 06:44, Vlad Khorsun wrote:
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.
On 2/10/22 15:57, Adriano dos Santos Fernandes wrote:
On 10/02/2022 06:59, Alex Peshkoff via Firebird-devel wrote:
If we need to take roles into an account - only for attachment with same
USER.
Even without shared cache, user can change its roles with SET ROLES and
new prepared statements
Adriano dos Santos Fernandes wrote 10.02.2022 14:08:
Some times yes, some times no (it's identical statement reprepared or
executed).
In this case you could ask IBSurgeon for their statistics about query
prepare/execute ratio beforehand to estimate possible gain from the cache. IIRC
during
On 10/02/2022 10:04, Dimitry Sibiryakov wrote:
> Adriano dos Santos Fernandes wrote 10.02.2022 13:56:
>> But it's not surprise that many applications are not well coded and
>> sometimes does not do this. Competitor DBMSs has cache and works well in
>> this case too.
>
> Such applications used
Adriano dos Santos Fernandes wrote 10.02.2022 13:56:
But it's not surprise that many applications are not well coded and
sometimes does not do this. Competitor DBMSs has cache and works well in
this case too.
Such applications used to build the queries ad-hock with data as literals.
The
On 10/02/2022 07:36, Dimitry Sibiryakov wrote:
> Alex Peshkoff via Firebird-devel wrote 10.02.2022 10:59:
>>> 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 we need
On 10/02/2022 06:59, Alex Peshkoff via Firebird-devel wrote:
>
> If we need to take roles into an account - only for attachment with same
> USER.
>
Even without shared cache, user can change its roles with SET ROLES and
new prepared statements should work as before even when they were
On 10/02/2022 06:44, Vlad Khorsun wrote:
> 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
Alex Peshkoff via Firebird-devel wrote 10.02.2022 10:59:
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 we need to take roles into an account - only for attachment with same USER.
On 2/10/22 12:44, Vlad Khorsun wrote:
I've peek these:
- statement text
- clientDialect
- isInternalRequest
Why it is important ? Do we have internal DSQL requests now ?
Yes we have - but not too much.
Is it makes sense to have two caches - for internal and for user
statements ?
-
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
35 matches
Mail list logo
