Recommended GUC Settings

PostgreSQL's defaults favor safety over observability. Most of them have to, given that PG runs everywhere from a Raspberry Pi to a 96-core production cluster. But a handful of changes lift MonPG's data quality dramatically without meaningfully hurting performance, and this page is the list of which ones.

What we recommend

Setting	Recommended	Restart?	Why
track_io_timing	on	No	Per-block I/O latency. Costs 5-10% CPU on write-heavy workloads. Without this, most I/O metrics report zero.
pg_stat_statements.track	top	No	Track top-level statements only. all is noisier and rarely useful.
pg_stat_statements.max	10000	Yes	The default 5k evicts long-tail queries on high-QPS clusters, which is exactly the data you want to keep.
pg_stat_statements.track_utility	on	No	Captures VACUUM, CREATE, etc. Useful for the maintenance view.
pg_stat_statements.save	on	No	Persists across restart so you don't lose the catalog every reboot.
track_activity_query_size	4096	Yes	Default 1024 truncates long queries; 4096 covers most ORM-generated SQL.
log_min_duration_statement	1000	No	Logs queries slower than 1s. Feeds Log Insights and Query Advisor.
log_lock_waits	on	No	Logs lock waits past deadlock_timeout. Saves you during incident review.
log_checkpoints	on	No	WAL checkpoint events. Tells you whether checkpoints are timed or forced.
log_autovacuum_min_duration	1000	No	Logs autovacuum runs over 1 second. The starting point for vacuum tuning.
auto_explain.log_min_duration	5000	No	Plan-capture threshold (5s). Needs auto_explain in SPL.
auto_explain.log_analyze	on	No	Includes EXPLAIN ANALYZE — the actual numbers, not estimates.
auto_explain.log_buffers	on	No	Buffer usage in plan output. Lets us spot cold-cache reads.
auto_explain.log_format	json	No	Parsable by the collector. Text format works but JSON is faster.
auto_explain.log_nested_statements	on	No	Captures function/trigger plans, which are usually where the slow query is hiding.

How to apply them

MonPG never modifies your GUCs in hosted onboarding. The Settings → Tuning page surfaces current versus recommended as a read-only diff so you can see exactly what would change. You apply the changes through your provider's config surface when convenient — usually during a planned maintenance window if any of the values need a restart.

The path differs by provider. On AWS RDS or Aurora, it's Parameter Groups; reboot for any restart-bound value. On Azure Flexible Server, the Server parameters blade — and ALTER SYSTEM is blocked, so don't try it. Google Cloud SQL exposes flags (some SPL-bound ones use the cloudsql.* prefix). Heroku has heroku pg:settings for a small set of exposed knobs and the rest are locked. Self-hosted is the easiest case: edit postgresql.conf + SELECT pg_reload_conf(); for reload-capable settings, full restart for postmaster-context ones.