Per pagespace I/O statistics and new trace API interfaces to allow extendable statistics #8808

dyemanov · 2025-11-22T11:26:15Z

Deprecate non-extendable PerformanceInfo struct in favor of the new PerformanceCounters/PerformanceStats interfaces
Adjust the trace implementation to the new API
Add internal support for per-pagespace I/O statistics. It's not used now, but will be used by PR Support for tablespaces #8314. This part is moved here to simplify review of the tablespaces.

…e PerformanceInfo struct in favor of the new PerformanceCounters/PerformanceStats interfaces. Adjust the trace implementation to the new API.

aafemt · 2025-11-22T11:29:22Z

Documentation is missing.

aafemt · 2025-11-22T11:31:58Z

src/include/firebird/FirebirdInterface.idl

+	uint64 getElapsedTime();	// in milliseconds
+	uint64 getFetchedRecords();
+
+	PerformanceCounters getGlobalCounters();


If you claim expandability, this must be one function with enum parameter: cGlobal, cPage, cRelation.

We can easily add more functions to extend the interface. But I may agree a single function would be simpler.

aafemt · 2025-11-22T11:33:18Z

src/include/firebird/FirebirdInterface.idl

+
+	uint getId(uint index);
+	const string getName(uint index);
+	const int64* getCounterVector(uint index);


TTL of returned value is...?

TTL of returned value is...?

It corresponds to the object TTL.

Well... Returning of a plain array is simple and effective, but doesn't quite fit the ideology of OO API. How about returning of another object with methods getRead, getWrites, getFetches, etc? In this case getVectorCapacity is not needed (I guess).

Valid point that I don't have a strong opinion about. Given the performance stats being somewhat low-level thing, I tried to follow the old-style interface with struct and counter vector, just made it extendable for new counter groups. Also, when we add new counters into the engine they automatically become available in the API, even being undocumented as enum members they're still usable without the need to recompile your trace plugin. With the pure OO approach the trace plugin should be recompiled to utilize new interface methods (and they should be added every time we add new counters).

@AlexPeshkoff @hvlad @asfernandes What do you think about this?

I do not think that adding separate method for each counter is good idea. An additional argument not to follow OO rules too strict here is that calling virtual function once and working with array elements after it should be faster than calling N virtual functions.

Also, when we add new counters into the engine they automatically become available in the API, even being undocumented as enum

How do a v7 caller of this interface can know the returned array from a v6 implementation does not have its expected items?

That's NOT the reason.

In the beginning I voted for pure virtual interfaces. That time non-virtual CLOOP functions was argument against them.

Looks like you missed the whole thing or are insisting on bad things 20 years later. Virtual functions has no standard ABI layout between different compilers.

Virtual functions has no standard ABI layout between different compilers.

You are dead wrong.

I do not think that adding separate method for each counter is good idea. An additional argument not to follow OO rules too strict here is that calling virtual function once and working with array elements after it should be faster than calling N virtual functions.

+1

Also, when we add new counters into the engine they automatically become available in the API, even being undocumented as enum

How do a v7 caller of this interface can know the returned array from a v6 implementation does not have its expected items?

If you want to access 9th counter, but getVectorCapacity() returns 7, then you're out of luck.

aafemt · 2025-11-22T11:34:38Z

src/include/firebird/FirebirdInterface.idl

+	uint getVectorCapacity();
+
+	uint getId(uint index);
+	const string getName(uint index);


ID and name of... what?

ID and name of... what?

Object (table, tablespace, whatever) counters belong to. Would you suggest getObjectId() / getObjectName()?

No, I just wonder what these methods shall return for Global and Page counters.

Nothing (zero) for global, valid id/name otherwise.

Perhaps, it could be useful to return hardcoded "Global" and "Pages" in these cases...

Would you suggest getObjectId() / getObjectName()?

Yes, please. Now it is confusing as could be read as ObjectName or CounterName

No, I just wonder what these methods shall return for Global and Page counters.

Thinking twice, I suppose getGlobalCounters() is not needed at all. Currently, it's used only to report page-level stats in the trace and this output will be modified anyway when tablespaces are merged (per-tablespace stats will be printed instead). And any global counter may be aggregated manually from the appropriate PerformanceCounters interface.

dyemanov · 2025-11-22T12:22:58Z

Documentation is missing.

True, to be added.

hvlad · 2025-11-24T12:15:16Z

src/include/firebird/FirebirdInterface.idl

+interface PerformanceCounters : Versioned
+{
+	uint getCount();
+	uint getVectorCapacity();


What it purpose of this method ? Why getCount() is not enough ?

getCount() returns a number of objects (tables, tablespaces, etc), each of them has a vector of getVectorCapacity() counters. getVectorCapacity() is intended to ensure compatibility without interface versioning -- you can easily check whether the engine supports the counter you'd like to access.

I suppose getObjectCount() would suit better here, given we discuss getObjectId() / getObjectName().

I would suggest maxCounter because it is count of counters, not objects, and it is constant for every object/counter's set.

dyemanov · 2025-11-26T08:22:33Z

Documentation is missing.

True, to be added.

The trace interfaces seem being not documented entirely, see Using_OO_API.md:

This document is currently missing 2 types of plugins – ExternalEngine and Trace. Information about them will be made available in next release of it.

I'm not in position to document the whole bunch of the trace interfaces right now, sorry. So documentation gonna be deferred.

aafemt · 2025-11-26T08:25:09Z

I'm not in position to document the whole bunch of the trace interfaces right now, sorry.

Limit to your new interfaces and methods.

…e separate global counters. Misc renaming.

dyemanov added 2 commits November 18, 2025 17:51

Add support of grouping page-level I/O counters per pagespace

9304339

Add support for per-pagespace I/O statistics. Deprecate non-extendabl…

e0817d0

…e PerformanceInfo struct in favor of the new PerformanceCounters/PerformanceStats interfaces. Adjust the trace implementation to the new API.

dyemanov self-assigned this Nov 22, 2025

aafemt reviewed Nov 22, 2025

View reviewed changes

hvlad reviewed Nov 24, 2025

View reviewed changes

dyemanov added 2 commits November 26, 2025 13:28

Better names for interface methods. Add the basic docs. Get rid of th…

45ec316

…e separate global counters. Misc renaming.

Add the docs weirdly escaped from the last commit

089060f

Uh oh!

Per pagespace I/O statistics and new trace API interfaces to allow extendable statistics #8808

Are you sure you want to change the base?

Per pagespace I/O statistics and new trace API interfaces to allow extendable statistics #8808

Conversation

dyemanov commented Nov 22, 2025

Uh oh!

aafemt commented Nov 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dyemanov commented Nov 22, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dyemanov Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dyemanov commented Nov 26, 2025

Uh oh!

aafemt commented Nov 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dyemanov Nov 24, 2025 •

edited

Loading