On 29/09/2020 13:43, Dmitry Yemanov wrote: > 28.09.2020 20:44, Adriano dos Santos Fernandes wrote: >> >> I have thought on that possibility since the start and the conflict >> points I see are: >> - Name of RDB$PROFILE_STATS - perhaps RDB$PROFILE_PSQL? > > Maybe we may leave it as is. And add RDB$PROFILE_CURSOR_STATS. > > The question is how they should be linked. Some artificial unique > cursor ID added to RDB$PROFILE_STATS for lines containing queries? Or > should RDB$PROFILE_CURSOR_STATS duplicate LINE/COLUMN as a reference? > What if the statement has multiple sub-queries? >
I have started to prototype this. Note that standalone SQL statements (not within an execute block or routine) may also be profiled and will not have line/column statement to be linked. Also, explicit cursors have a declaration line but each operation happens in a different line. In this case, I think the stats should have the declaration line. Individual cursor statements will be accounted as PSQL statements in their respective lines. Given this, I'm thinking in duplicate line/column instead of link. RDB$PROFILE_CURSOR_STATS will have a parent ID (linked to the artificial cursor ID) creating a recursive structure modeling RecordSource (detailed plain). > BTW, execution time is good but I believe all other statistics > (page-level, record-level, memory) should also be collected/reported > while profiling. Mostly this is about cursors, but not only (singleton > INSERTs for example). > How exactly that will not be duplicated (i.e., user and engine cannot sum these things and we store an aggregation)? Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
