Ways to get a list of tables affected by a transaction in a Trace Plugin?

[Maxim Kryukov]

Hi all,
In my custom Trace Plugin I would like to collect the names of tables whose data has been modified in a transaction between transaction start and commit events. I see two methods: 1) install triggers on insert/update/delete for every table and proccess trigger run event; and 2) process execute statement events to parse sql statements; not sure how to handle stored procedures (dive into BLR?), more confused about handling external functions.
Are there any other ways to achieve this within a Trace Plugin?

[Vlad Khorsun]

24.05.2026 20:24, 'Maxim Kryukov' via firebird-devel:

Use per-table counters that is available in PerformanceInfo returned by TraceTransaction.getPerf();

Regards,
Vlad

[mxck]

Thank you very much indeed, my fault I missed it. Hope PerformanceInfo
has enough info in FB 3.0.8 tag, will know soon.

[Maxim Kryukov]

In PerformanceInfo* perf returned by TraceTransaction.getPerf() I always get:

perf->pin_count == 0
perf->pin_tables is *NOT* NULL (?)
perf->pin_time == 0
perf->pin_records_fetched == 0

I call  TraceTransaction.getPerf() in ITracePlugin.trace_transaction_end()

Should I setup  PerformanceInfo collection somehow?

[Dimitry Sibiryakov]

'Maxim Kryukov' via firebird-devel wrote 04.06.2026 14:38:
> I call TraceTransaction.getPerf() in ITracePlugin.trace_transaction_end()
> Should I setup PerformanceInfo collection somehow?

End of transaction rarely affect tables. Queries do. You must collect
performance data on dsql/prorcedure/trigger/etc execute.

--
WBR, SD.

[Maxim Kryukov]

My intuition played tricks on me making me believe there would be cumulative stats for a whole transaction lifetime (at this moment transaction ends, doesn't it?).

Not the case.

In this case Vlad  Khorsun's remark should be read as ' Use per-table counters in PerformanceInfo returned by  every trace event'.

And why  perf->pin_tables is *NOT* NULL? Where does it point to?

четверг, 4 июня 2026 г. в 15:42:39 UTC+3, Dimitry Sibiryakov:

[Dimitry Sibiryakov]

'Maxim Kryukov' via firebird-devel wrote 04.06.2026 15:25:
> And why perf->pin_tables is *NOT* NULL? Where does it point to?

Array of counters of zero size.

--
WBR, SD.

[Maxim Kryukov]

So allocating a zero-size entity is to save some cpu cycles on nullptr check? You stil have to free this memory though. Was it done deliberately or is it just a side effect?

четверг, 4 июня 2026 г. в 16:38:53 UTC+3, Dimitry Sibiryakov:

[Dimitry Sibiryakov]

'Maxim Kryukov' via firebird-devel wrote 04.06.2026 15:51:
> So allocating a zero-size entity is to save some cpu cycles on nullptr check?

It is a HalfStaticArray, inline storage is not quite "allocated".

--
WBR, SD.

[Maxim Kryukov]

Thank you, I should drill on FB memory pools and the like.

четверг, 4 июня 2026 г. в 17:02:35 UTC+3, Dimitry Sibiryakov:

[Vlad Khorsun]

04.06.2026 16:25, 'Maxim Kryukov' via firebird-devel:

> My intuition played tricks on me making me believe there would be cumulative stats for a whole transaction lifetime (at this moment
> transaction ends, doesn't it?).

Engine collect such stats, but it is not available via Trace API.

> Not the case.

Yes

> In this case Vlad Khorsun's remark should be read as ' Use per-table counters in PerformanceInfo returned by */every trace event/*'.

Yes, sorry or confusion. trace_transaction_end() shows stats for this event only.
It will be non-empty in case of DDL statements was executed within transaction.
So, it looks like you need to collect and accumulate per-transaction stats at
trace_dsql_execute() and add stats from trace_transaction_end().

> And why perf->pin_tables is *NOT* NULL? Where does it point to?

It should not bother you as soon as pin_count == 0.

Regards,
Vlad