# Should we enable pgsm\_normalized\_query or not? — Missing QAN examples on PMM 3.8.1 **URL:** \ **Category:** Uncategorized\ **Created:** [July 29, 2026, 4:50pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110 "2026-07-29T16:50:20Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [July 29, 2026, 4:50pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/1 "2026-07-29T16:50:20Z")
Hi team, Following up on this earlier thread: [No query examples in PMM QAN with pg\_stat\_monitor normalized queries enabled](https://forums.percona.com/t/no-query-examples-in-pmm-qan-with-pg-stat-monitor-normalized-queries-enabled/40209) We’re on **PMM 3.8.1** monitoring PostgreSQL with `pg_stat_monitor`, and confirmed the same behavior: with `pgsm_normalized_query = on`, QAN’s Examples tab shows “Sorry, no examples found for this query” since the normalized `query` column only stores placeholders (`$1`, `$2`) and never the literal values. This is tracked as **PMM-13195** , but we need to decide our config going forward, so a few questions: 1. **What’s Percona’s actual recommendation** — should we run with `pgsm_normalized_query = on` or `off` in production? The install docs recommend `on` but that silently disables Examples, which seems like an important trade-off to flag. 2. If we turn it `off` to get Examples back, are there **known downsides** beyond the Table/Plan behavior mentioned in the earlier thread — e.g. performance overhead of storing literal query text, memory/storage growth in `pg_stat_monitor`’s shared buffer, or security/PII exposure from capturing literal values? 3. Is there a way to get **both** — normalized aggregation _and_ example queries — short of waiting on [pg\_stat\_monitor PR #350](https://github.com/percona/pg_stat_monitor/pull/350) (the stalled `bind_variables` column)? 4. Any ETA or plan for **PMM-13195** , and would it help if we added our environment details/+1 to that ticket? Environment: - PMM: 3.8.1 - Database: PostgreSQL 17 version - Extension: pg\_stat\_monitor (via `shared_preload_libraries`) - Current: `pgsm_normalized_query = on` Would really appreciate guidance on which setting to run with, since Examples are important for us to debug slow queries but we don’t want to break aggregation or hit hidden costs. Thanks! ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [July 30, 2026, 9:51am UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/2 "2026-07-30T09:51:29Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 3, 2026, 4:55am UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/3 "2026-08-03T04:55:04Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 4, 2026, 2:18am UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/4 "2026-08-04T02:18:58Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 5, 2026, 3:32pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/5 "2026-08-05T15:32:19Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 10, 2026, 1:57pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/6 "2026-08-10T13:57:41Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 13, 2026, 1:27pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/7 "2026-08-13T13:27:59Z")
Can someone help me on this issue? ---
**Author:** ![Naresh9999](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/naresh9999/32/5568_2.png) [@Naresh9999](https://forums.percona.com/u/Naresh9999)\ **Post date:** [August 17, 2026, 12:25pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/8 "2026-08-17T12:25:27Z")
Can someone help me on this issue? ---
**Author:** ![ademidoff](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/ademidoff/32/14234_2.png) [@ademidoff](https://forums.percona.com/u/ademidoff)\ **Post date:** [August 23, 2026, 7:58pm UTC](https://forums.percona.com/t/should-we-enable-pgsm-normalized-query-or-not-missing-qan-examples-on-pmm-3-8-1/41110/9 "2026-08-23T19:58:44Z")
Thanks for the detailed writeup — you’ve found a real gap in our docs. The short answer is that the right setting depends on how your app sends SQL, not on your PMM version. If your queries arrive with literals inlined (simple protocol — psql, string-built SQL, ORMs not using prepared statements): set `pgsm_normalized_query = off`. You get Examples back and lose nothing on aggregation, because pmm-agent normalizes the query itself on the client side when the userset parameter is off. If your queries use server-side prepared statements (JDBC and most drivers with prepared statements): the setting changes nothing. `pg_stat_monitor` never stores bind values, so the text stays `WHERE id = $1` either way, and no configuration fixes that today. 1. Our recommendation, and the docs bug. The pgsm\_normalized\_query = 1 line under “Recommended settings” in our install guide never got the caveat it needs. Upstream’s default has been off since pg\_stat\_monitor 1.1.0 — changed deliberately (PG-362) so examples work out of the box. Our “recommended” value is the one that suppresses them. We’re fixing that. 2. Downsides of off — verified on PostgreSQL 17.9 with pg\_stat\_monitor 2.3: - Aggregation: unaffected. The bucket hash key contains no query text; queryid is PostgreSQL’s own parse-tree hash and `pgsm_query_id` is always computed on the normalized text. Same statement with different literals gives identical IDs in both modes. - DB CPU: no change. PGSM normalizes anyway to compute `pgsm_query_id`, so off neither saves nor costs anything there. - Shared buffer: no entry explosion. One text per hash entry per bucket, first execution wins (two literal variants collapsed into one row with calls = 2). Literal text is just somewhat longer than the placeholder form. - Truncation is the one real downside. PGSM cuts stored text at `pgsm_query_max_len` (2048 default — a 2729-char statement came back as exactly 2048). pmm-agent can’t parse truncated SQL, so it falls back to using the truncated literal as the fingerprint. Long statements — big IN lists, multi-row INSERTs — will show literal values instead of a clean fingerprint. With on that can’t happen. 1. Getting both. For simple-protocol traffic, off already is both. For bind parameters, no — and don’t wait on PR #350: it was closed unmerged in March 2026, with the maintainer noting a `bind_variables` column adds nothing over `pgsm_normalized_query = off`. 2. PMM-13195. Straight answer: Open, unassigned, no fixVersion; the “3.X” marker means no committed release. We reproduced it in 2024 and it stalled because the remaining part isn’t fixable in PMM alone — QAN can only show what `pg_stat_monitor stores`. Your ping on the ticket also went unanswered, which is on us. Please do add your environment, specifically: which driver and whether it uses server-side prepared statements; `SELECT name, setting FROM pg_settings WHERE name LIKE 'pg_stat_monitor.%';` and whether Examples appear for some queries after switching to off. That’s what we need to split the ticket into its two real cases. What we can commit to now is the docs fix — the trade-off next to the recommendation, plus a PostgreSQL entry in QAN troubleshooting (today’s “no examples found” guidance is MySQL-only). Which case are you in? ```bash ALTER SYSTEM SET pg_stat_monitor.pgsm_normalized_query = off;SELECT pg_reload_conf(); -- run your workload for a bucket or two, then: SELECT calls, left(query, 80) AS query FROM pg_stat_monitor WHERE query LIKE '%$1%' LIMIT 10; ``` Rows still containing $1 are extended-protocol statements — no examples possible. Rows with literals will appear in QAN’s Examples tab.