Add trace_fetch events to monitor client row fetching

[Maxim Kryukov]

Hi all!

  Did anyone ever consider adding trace_fetch events to monitor client row fetching?  

[Dimitry Sibiryakov]

'Maxim Kryukov' via firebird-devel wrote 05.06.2026 13:16:
>   Did anyone ever consider adding trace_fetch events to monitor client row
> fetching?

Because of client and server both doing prefetch it is completely useless.

--
WBR, SD.

[Vlad Khorsun]

05.06.2026 14:16, 'Maxim Kryukov' via firebird-devel:

> Hi all!
>   Did anyone ever consider adding trace_fetch events to monitor client row fetching?

It will pollute trace log with a lot of events and kill server performance,
if I get what you means. Also, due to network server batching, it will not match
the client observations.

Regards,
Vlad

PS the same about blob and generator related actions.

[Maxim Kryukov]

It will pollute trace log with a lot of events and kill server performance

 

I didn't intend to add to a human log, just an event for TracePlugin

 

Also, due to network server batching, it will not match
the client observations.

 

The reason I thought of such events is probably my misunderstanding of exec statement stats. In TracePlug we have dsql_exec START and dsql_exec FINISH. I guess fetching goes in between. What is the execution time retrieved in exec FINISH? Time to readiness to give a client a first record, or all the time up to FINISH? 

In the latter case it might take days if a client is lazy or unwilling to fetch further.

So the reason is to notice the heartbeat of fetch traffic, either batched/prefetched or otherwise.

Another wish is to fish out statements taking relatively fast to execute, but taking much more time to drain records.

[Dimitry Sibiryakov]

'Maxim Kryukov' via firebird-devel wrote 05.06.2026 14:12:
> The reason I thought of such events is probably my misunderstanding of exec
> statement stats. In TracePlug we have dsql_exec START and dsql_exec FINISH. I
> guess fetching goes in between.

No. Every fetch calls `trace_dsql_execute` with `starting` set to `false`.
You indeed should dig into Firebird sources.

--
WBR, SD.

[Maxim Kryukov]

No. Every fetch calls `trace_dsql_execute` with `starting` set to `false`.

 

Then it already is an alias to 'trace_fetch'.

 

You indeed should dig into Firebird sources.

I know. But you are so kind and fast. Thank you. Will restrain to distract you. 

[Vlad Khorsun]

05.06.2026 15:25, 'Dimitry Sibiryakov' via firebird-devel:

> 'Maxim Kryukov' via firebird-devel wrote 05.06.2026 14:12:
>> The reason I thought of such events is probably my misunderstanding of exec statement stats. In TracePlug we have dsql_exec START
>> and dsql_exec FINISH. I guess fetching goes in between.
>
>   No. Every fetch calls `trace_dsql_execute` with `starting` set to `false`.

Only the last one, when EOF reached.

>   You indeed should dig into Firebird sources.

Will not harm. And same for you.

Regards,
Vlad

[Vlad Khorsun]

05.06.2026 15:12, 'Maxim Kryukov' via firebird-devel:

> It will pollute trace log with a lot of events and kill server performance
>
> I didn't intend to add to a human log, just an event for TracePlugin

Trace was implemented for human log in first place. And to not hurt performance much.

> Also, due to network server batching, it will not match
> the client observations.
>
> The reason I thought of such events is probably my misunderstanding of exec statement stats. In TracePlug we have dsql_exec START
> and dsql_exec FINISH. I guess fetching goes in between. What is the execution time retrieved in exec FINISH? Time to readiness to
> give a client a first record, or all the time up to FINISH?

Cumulative time spend when the engine handle calls of execute and all fetches up to EOF.

> In the latter case it might take days if a client is lazy or unwilling to fetch further.

So what ? Why Trace API should care about it ?

> So the reason is to notice the heartbeat of fetch traffic, either batched/prefetched or otherwise.
> Another wish is to fish out statements taking relatively fast to execute, but taking much more time to drain records.

It is not possible with current Trace API interfaces. But, of course, it might
be extended in this direction. If really necessary.

Regards,
Vlad

[Maxim Kryukov]

Trace was implemented for human log in first place.

> In the latter case it might take days if a client is lazy or unwilling to fetch further.
So what ? Why Trace API should care about it ?

I still think some kind of separation of execution budget into initial processing and fetching phases would be of help to many DBAs, if the phases are distinguishable at all. I remember the hard times we had trying to figure out the most greedy queries on outdated hardware. We scrutinized Trace API logs. We chose the statement's exec time as the primary metric. But being presented with a complete exec time (with fetching) may lead to false optimizations. The most resource-hogging queries were not from an accounting system (lasting fifteen seconds), but perhaps a bunch of queries that lasted 1.5 seconds, but had weird plans.

If really necessary.

 It is not about money.

[Vlad Khorsun]

05.06.2026 17:10, 'Maxim Kryukov' via firebird-devel:

I still not understand what you speak about: some complains ? some proposition ? What it is all about ?

> If really necessary.
>
>
>  It is not about money.

I'm completely lost you here, sorry

Regards,
Vlad

[Maxim Kryukov]

It is a 'weak' proposal. I wanted some advice on estimating fetch times as part of execution time. Within a trace plugin. I sort of got the answers. Thank you!

Feel free to 'close' the subject.

пятница, 5 июня 2026 г. в 17:14:41 UTC+3, Vlad Khorsun:

[Vlad Khorsun]

> It is a 'weak' proposal. I wanted some advice on estimating fetch times as part of execution time.

Looks like you assume that query execution is complete before the first fetch.
This is far from true.

Regards,
Vlad