Commented by: @dyemanov

The problem is that measuring time also takes time, thus affecting performance. And given that you need to exclude "stalled" intervals, timer should be reset for the every fetched record. For trivial queries that return many rows it may be an overkill.

IMO, it should be either configurable (and disabled by default), or moved to the trace side (which is already optional and configurable), or be part of the SQL profiler feature that was discussed in fb-devel.

Commented by: @livius2

First we must define what "stalled" mean and what really is needed (maybe other word).

I need to calculate time when there is request from client to server to retrive data for this query.
Because this calculation " timer should be reset for the every fetched record" is not needed.
As client do not ask server for every record, this will be overkill in round trips from client to server i suppose.

We only need to exclude time when client do not read data from the server.
Maybe something like MON$READ_TOTAL_TIME and MON$READ_IDLE_TIME will be better here and easier to calculate without affecting performance instead of MON$ELAPSED_TIME which will be ideal but...

Or any other proposition that satisfy needs :)

Commented by: @livius2

As Firebird4 is RC and near to release, some question arrise - "Statement Timeout".
Will this stalled query be timeouted? Or timeout is calculated on real query execution time?

Commented by: @hvlad

Karol,

in short: yes, stalled query could be timed out.

Actually, your question is already answered in Release Notes, see "How the Statement Timeout Works" at "Chapter 3. Changes in the Firebird Engine".