You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using PGSM V2.0.0 and pg_stat_monitor.pgsm_enable_query_plan is enabled. We can see the following output:
postgres=# SELECT Sum(calls) AS calls,
postgres-# query :: VARCHAR(100) AS QUERY,
postgres-# query_plan :: VARCHAR(500) AS query_plan,
postgres-# (SELECT Round(Sum(shared_blks_hit) :: DECIMAL, 2)
postgres(# FROM pg_stat_monitor) AS total_shared_blks_hit,
postgres-# Round(Sum(shared_blks_hit) :: DECIMAL, 2) AS shared_blks_hit,
postgres-# Round(( ( Sum(shared_blks_hit) ) * 100 ) / (SELECT Sum(shared_blks_hit)
postgres(# FROM pg_stat_monitor) ::
postgres(# DECIMAL,
postgres(# 2) AS "shared_blks_hit [%]"
postgres-# FROM pg_stat_monitor
postgres-# GROUP BY query,
postgres-# query_plan
postgres-# ORDER BY "shared_blks_hit [%]" DESC
postgres-# LIMIT 10;
calls | query | query_plan | total_shared_blks_hit | shared_blks_hit | shared_blks_hit [%]
--------+------------------------------------------------------------------------------------------------------+------------------------------------------------------------+-----------------------+-----------------+---------------------
543586 | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2 | | 14709314.00 | 6105878.00 | 41.51
543586 | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2 | | 14709314.00 | 2765381.00 | 18.80
543586 | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2 | | 14709314.00 | 2737817.00 | 18.61
1 | vacuum analyze pgbench_accounts | | 14709314.00 | 821952.00 | 5.59
543585 | INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES ($1, $2, $3, $4, CURRENT_TIMESTAMP) | | 14709314.00 | 562217.00 | 3.82
5000 | insert into pgbench_tellers(tid,bid,tbalance) values ($1,$2,$3) | | 14709314.00 | 5051.00 | 0.03
1 | alter table pgbench_accounts add primary key (aid) | | 14709314.00 | 2220.00 | 0.02
1 | SELECT abalance FROM pgbench_accounts WHERE aid = $1 | Index Scan using pgbench_accounts_pkey on pgbench_accounts+| 14709314.00 | 6.00 | 0.00
| | Index Cond: (aid = 1389835) | | |
1 | SELECT abalance FROM pgbench_accounts WHERE aid = $1 | Index Scan using pgbench_accounts_pkey on pgbench_accounts+| 14709314.00 | 6.00 | 0.00
| | Index Cond: (aid = 10119771) | | |
1 | SELECT abalance FROM pgbench_accounts WHERE aid = $1 | Index Scan using pgbench_accounts_pkey on pgbench_accounts+| 14709314.00 | 6.00 | 0.00
| | Index Cond: (aid = 30365540) | | |
(10 rows)
Since I am using pg_stat_monitor.pgsm_normalized_query enabled, the queries do not expose the bind variable values. E.g.:
SELECT abalance FROM pgbench_accounts WHERE aid = $1
This helps to hide potentially sensitive data (E.g.: credit card numbers or whatever else), but we also have the chance to set {{pg_stat_monitor.pgsm_normalized_query }}to disabled. And it helps to troubleshoot problems with data cardinality.
When checking the query plan, we ALWAYS expose the execution plan and the bind variable values we used.
Having a flag similar to pgsm_normalized_query for the plans would be great. This would allow us to expose or hide information depending on the case.
I still think that getting the chance to expose data or not is the way to go. It provides a strong power when troubleshooting unstable execution plans.
When using PGSM V2.0.0 and pg_stat_monitor.pgsm_enable_query_plan is enabled. We can see the following output:
Since I am using pg_stat_monitor.pgsm_normalized_query enabled, the queries do not expose the bind variable values. E.g.:
This helps to hide potentially sensitive data (E.g.: credit card numbers or whatever else), but we also have the chance to set {{pg_stat_monitor.pgsm_normalized_query }}to disabled. And it helps to troubleshoot problems with data cardinality.
When checking the query plan, we ALWAYS expose the execution plan and the bind variable values we used.
Having a flag similar to pgsm_normalized_query for the plans would be great. This would allow us to expose or hide information depending on the case.
I still think that getting the chance to expose data or not is the way to go. It provides a strong power when troubleshooting unstable execution plans.
Best Regards,
https://jira.percona.com/browse/PG-630
The text was updated successfully, but these errors were encountered: