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
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 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
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
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
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
Hello!
There are 2 threads: PSQL profiler and SQL profiler. I've decided to
continue here)
It seems to me that profiling only the same attachment is not as
useful as it could be.
Imagine a working application. It's ready but you want to know where
it spends time. You attach to the server by
06.11.2021 10:30, Omacht András wrote:
it's November now.
Any chance of coming out in the near future?
3.0.7 was released October 20, 2020.
I'm going to tag the tree tomorrow. The release will come shortly after.
Dmitry
Firebird-Devel mailing list, web interface at
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
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"
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 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?
13 matches
Mail list logo
