pg_stat_monitor: PostgreSQL's pg_stat_statements compatible view.
Description
How to document
How to test
blocks
duplicates
Activity
Hamid Akhtar January 16, 2023 at 1:48 PMEdited
We need to make the following changes:
pgsm:
dbid => add column
userid => data type to oid
user => column added for user name
queryid => data type to bigint (remove hex)
top_queryid => data type to bigint (remove hex)
plans_calls => change column name to plans
rows_retrieved => change column name to rows
Ibrar Ahmed December 21, 2022 at 1:21 PM
We have done some analysis on that and found that it will create more confusion if we change the behaviour of pg_stat_monitor to pg_stat_statment. There are other ways to change the column name of pg_stat_monitor to pg_stat_statments, but it has some issues.
1 - PMM needs to change the name and comments at their end.
2 - PMM need to run some sub-queries to generate readable data; for example, if we expose dbid instead of the database name, then PMM need to query the database for the database name based on dbid.
3 - If we add duplicate name columns, it becomes a readability issue and creates confusion.
I am dropping that idea now and will discuss it in more detail.
Details
Details
Assignee
Reporter
Labels
Time tracking
Components
Fix versions
Affects versions
Priority
Medium
Smart Checklist
Open Smart Checklist
Smart Checklist
We need to create a view in pg_stat_monitor to show the pg_stat_statemnsts-like view. This will eliminate the need of pg_stat_statements. There is a need for that because if the user needs both extensions then he has to load both extensions and this will cause a double performance hit. If pg_stat_monitor provides both capabilities, then it will be very easy adoption of pg_stat_monitor.
As part of this change, we must also check if pg_stat_statements is already installed as we can't have the same view in the same schema.
We don't create a view for pg_stat_statements. We have the same column names and the same data types for the matching columns.