PSQL and SQL profiler #285
Conversation
|
If start_session returns session id and multiple session can be started simultaneously (according to the table RDB$PROFILE_SESSIONS), shouldn't all other procedures accept session id as a parameter to know which session to work with? |
Sessions cannot be started simultaneously. Only last started session is active. Docs says that start_session could be called with a session already started and it has the same effect as finishing the first before start the second. |
|
In this case shouldn't RDB$PROFILE_SESSIONS also include finish time...?
|
| - `RDB$COUNTER` type `BIGINT` - Number of executed times of the statement | ||
| - `RDB$MIN_TIME` type `BIGINT` - Minimal time (in nanoseconds) of a statement execution | ||
| - `RDB$MAX_TIME` type `BIGINT` - Maximum time (in nanoseconds) of a statement execution | ||
| - `RDB$ACCUMULATED_TIME` type `BIGINT` - Accumulated execution time (in nanoseconds) of the statement |
There was a problem hiding this comment.
RDB$TOTAL_TIME maybe?
Agree.
There was a problem hiding this comment.
Should it be MIN/MAX TIME our MINIMUM/MAXIMUM?
Maybe... And also a description/comment passed in START_SESSION. |
- Added parameter DESCRIPTION to RDB$PROFILER.START_SESSION. - Renamed RDB$PROFILE_SESSIONS.RDB$TIMESTAMP to RDB$START_TIMESTAMP. - Added RDB$PROFILE_SESSIONS.RDB$FINISH_TIMESTAMP. - Renamed RDB$PROFILE_STATS.RDB$ACCUMULATED_TIME to RDB$TOTAL_TIME.
Add RDB$PROFILE_SESSIONS.RDB$ATTACHMENT_ID and RDB$PROFILE_SESSIONS.RDB$USER.
…PROFILE_SESSIONS. Disallow direct modifications in others profile tables. Add system privilege DELETE_ANY_PROFILE_SESSION and disallow deletion of others users' data without it. Rename procedure and parameters UPDATE_SNAPSHOT to REFRESH_SNAPSHOTS.
|
I propose change this PR creating a "profiler plugin API".
Tables will be created (explicitly or on-demand) by the profiler plugin, and as non-system tables, will be backed-up as user tables.
Engine as well will interact with profiler plugins active for the session. I'm not yet detailing plugin API, but it will support current operations. That will open path for real-time visual profile. A plugin could (directly to screen in case of embedded, or via inter-process/network communication) visually display what engine is being run, instead of store things. Plugin may also store data in different places than the database. |
|
HiI like the idea of "none system" tables but i dislike then RDB$ prefix.Regards,Karol Bieniaszewski
-------- Oryginalna wiadomość --------Od: Adriano dos Santos Fernandes ***@***.***> Data: 02.09.2021 19:48 (GMT+01:00) Do: FirebirdSQL/firebird ***@***.***> DW: Karol Bieniaszewski ***@***.***>, Comment ***@***.***> Temat: Re: [FirebirdSQL/firebird] PSQL and SQL profiler (#285)
I propose change this PR creating a "profiler API".
RDB$PROFILER package will still be an engine thing, but RDB$PROFILE_* tables will not.
Tables will be created (explicitly or on-demand) by the profiler plugin, and as non-system tables, will be backed-up as user tables.
RDB$PROFILER will call plugin methods. RDB$PROFILER.START_SESSION will receive list of profiler plugins and it will drive communication with them.
Engine as well will interact with profiler plugins active for the session.
I'm not yet detailing plugin API, but it will support current operations.
That will open path for real-time visual profile.
A plugin could (directly to screen in case of embedded, or via inter-process/network communication) visually display what engine is being run, instead of store things.
Plugin may also store data in different places than the database.
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
Replaced by #7086 |
No description provided.