On 10/11/2021 11:41, Dmitry Yemanov wrote:
> 09.11.2021 03:21, Adriano dos Santos Fernandes wrote:
>>
>> I think all statements should be split in MON$STATEMENTS and
>> MON$COMPILED_STATEMENTS.
>
> What about execute_immediate? Should they be reported only inside
> MON$STATEMENTS or also have a
09.11.2021 03:21, Adriano dos Santos Fernandes wrote:
I think all statements should be split in MON$STATEMENTS and
MON$COMPILED_STATEMENTS.
What about execute_immediate? Should they be reported only inside
MON$STATEMENTS or also have a record in MON$COMPILED_STATEMENTS but as
not shareable
On 08/11/2021 17:10, Mark Rotteveel wrote:
>> Also, if DSQL requests have stable ID, it's weird that more than one
>> called routines would be linked to it (even if not at the same time)
>> through MON$CALL_STACK (where request IDs are more correctly used).
>
> I'm confused about the case, or
On 08/11/2021 14:48, Dmitry Yemanov wrote:
> 08.11.2021 19:54, Adriano dos Santos Fernandes wrote:
>>
>> In this case I think we better sooner introduce MON$COMPILED_STATEMENTS
>> with some duplicate information already present in MON$STATEMENTS,
>
> Obviously, SQL text and plan belong to the
On 2021-11-08 17:54, Adriano dos Santos Fernandes wrote:
On 08/11/2021 12:11, Dmitry Yemanov wrote:
08.11.2021 17:54, Dimitry Sibiryakov wrote:
Nope, I believe the new ID must be generated also by findRequest()
if
the clone was found in the cache.
Will it make impossible to detect
08.11.2021 19:54, Adriano dos Santos Fernandes wrote:
In this case I think we better sooner introduce MON$COMPILED_STATEMENTS
with some duplicate information already present in MON$STATEMENTS,
Obviously, SQL text and plan belong to the statement. The rest looks
request-specific (timestamp
On 08/11/2021 14:05, Dimitry Sibiryakov wrote:
> Adriano dos Santos Fernandes wrote 08.11.2021 17:54:
>> The solution does not work for the profiler then.
>
> Why? Isn't the profiler supposed to help detect cases when fast (by
> itself) statement is executed enormous number of times degrading
Adriano dos Santos Fernandes wrote 08.11.2021 17:54:
The solution does not work for the profiler then.
Why? Isn't the profiler supposed to help detect cases when fast (by itself)
statement is executed enormous number of times degrading overall application
performance?..
--
WBR, SD.
On 08/11/2021 12:11, Dmitry Yemanov wrote:
> 08.11.2021 17:54, Dimitry Sibiryakov wrote:
>>
>>> Nope, I believe the new ID must be generated also by findRequest() if
>>> the clone was found in the cache.
>>
>> Will it make impossible to detect repeatable execution of a prepared
>> statement as
08.11.2021 17:54, Dimitry Sibiryakov wrote:
Nope, I believe the new ID must be generated also by findRequest() if
the clone was found in the cache.
Will it make impossible to detect repeatable execution of a prepared
statement as opposite for execution of a new one every time?
Dmitry Yemanov wrote 08.11.2021 15:28:
Is it an important design of MON$STATEMENTS that this (subsequent
execution of a request maintain its ID) happens?
Nope, I believe the new ID must be generated also by findRequest() if the clone
was found in the cache.
Will it make impossible to
08.11.2021 16:50, Adriano dos Santos Fernandes wrote:
Despite its name, what MON$STATEMENTS show are requests (not statements).
True, but statement/request separation didn't exist when MON$STATEMENTS
was implemented ;-) And end users deal with statements, they have no
idea what "request"
Hi!
Despite its name, what MON$STATEMENTS show are requests (not statements).
When a stored routine is executed, finished and executed again, its
request is re-used. Re-used request maintain its ID and is mapped to
MON$STATEMENTS.MON$STATEMENT_ID.
Is it an important design of MON$STATEMENTS
13 matches
Mail list logo