The problem: 

Users can change some defaults of PG_stat_monitor (pgsm) extension and add the PG server to PMM. This will lead to incorrect processing of data and presentation of them in PMM.

We don't want, as for now, to invest in covering all possible options on the PMM side so the approach is: verify the expected defaults of pgsm and warn the user that the options are NOT optimal.

Questions: How we should proceed with "unrecommended defaults"?

1. advise/warn users only 

2. warn and stop adding a system to monitoring. Allow to use "–force" flag for users to still add Service to PMM

3. don't have official user flag to overcome this defaults verification but have some PERCONA_TEST flag to overwrite the limitation (very internal flag )

UX:

TBD

pmm-admin add postgresql --query-source=pgstatmonitor .... 

List of PGSM settings we expect to be  critical as defaults:

1. pg_stat_monitor.pgsm_normalized_query = 0.  We need examples as advantages against  default extension 

2. pg_stat_monitor.pgsm_normalized_query = 2048 . We need longer queries to be tracked then 1024

3. pg_stat_monitor.pgsm_bucket_time = 60 . others values will brake qan presentation

4. pg_stat_monitor.pgsm_histogram_min ,  pg_stat_monitor.pgsm_histogram_max , pg_stat_monitor.pgsm_histogram_buckets  = 0, 100000, 10.   = We expect 10  ranges of histograms . if this changes - it's almost impossible to do histograms right on flight. 

Original report:

pg_stat_monitor.pgsm_normalized_query selects whether save query in normalized format. This is disabled by default.

We should show warning to users that once pg_stat_monitor.pgsm_normalized_query is enabled it will effect query examples - user will see "Sorry, no examples found for this query" when checking Examples tab in QAN.

1. Add message to pmm-admin add postgresql

2. Add to documentation