## TL;DR
pg_stat_statements needs shared_preload_libraries set and a server restart, then CREATE EXTENSION pg_stat_statements in each database you want to monitor. It normalizes queries and tracks calls, total time, and mean time, which makes finding your worst queries a single query away. Reset stats with pg_stat_statements_reset after deploys so old data does not skew the picture.

## The query
```text
postgres pg_stat_statements setup guide
```

## Use this when
- you need to find the slowest or most frequent queries in Postgres
- you are setting up monitoring on a new database
- pg_stat_statements views are empty and you do not know why

## Not for
- seeing currently running queries, which is pg_stat_activity
- query monitoring in other databases, which have their own tools

## Steps
1. Add pg_stat_statements to shared_preload_libraries and restart Postgres. The extension cannot load without the restart.
   Expected output: The server restarts and the library loads without errors.

2. Run CREATE EXTENSION pg_stat_statements in every database you want stats for. It is per-database, not global.
   Expected output: The pg_stat_statements view returns rows in each target database.

3. Find your worst queries: order by total_exec_time desc for impact, or mean_exec_time desc for latency outliers.
   Expected output: You have a ranked list of queries by total and mean time.

4. Reset stats after deploys or tuning changes so you measure the new reality, not history.
   Expected output: Post-deploy numbers reflect only post-deploy traffic.

5. Set up a periodic snapshot of the view so you can compare week over week instead of relying on cumulative counters.
   Expected output: Historical snapshots exist for trend analysis.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3_NOo81OV_F_quOa8Jwo2A