How do I log slow queries in Postgres?

Set a minimum duration, and every statement that runs longer is written to the log with its text and its elapsed time. It is reloadable, it costs nothing for statements under the threshold, and it is the one piece of query instrumentation that needs no extension and no restart. Start somewhere uninteresting, a second or two, and lower it once the volume proves manageable.

The settings around it that make the log usable

A threshold low enough to be interesting is often too noisy to keep. For that there is a sampling pair: a lower threshold above which statements become candidates, and a fraction of those candidates to actually log. It gives you a representative view of the middle of the distribution without logging all of it, and the hard threshold still logs everything above it unconditionally.

Turn on temporary file logging at the same time. A query that spills a sort to disk is frequently the one you are hunting, and the line it produces names the size, which is a much sharper signal than duration alone. Temporary files covers what causes the spill.

Then spend some effort on the line prefix. A log line with the user, database, application name and transaction identifier attached is evidence; the same line without them is an anecdote, and the difference costs one configuration setting.

While you are in there, check what else is being logged, because defaults have moved. Checkpoint logging and slow autovacuum logging have been on by default since PostgreSQL 15, but a configuration file copied forward from an older cluster keeps the old silence, which is how a modern server ends up with a decade-old logging policy.

What the log cannot tell you

It shows slow executions, not expensive queries. A statement that takes ten milliseconds and runs a hundred thousand times an hour never crosses any threshold worth setting and may be the largest consumer on the server. That is the gap the statement statistics extension fills, and whether it is safe to enable in production covers the cost of doing so.

If you need the plan of the slow execution rather than just its text, the automatic explain module logs it alongside, and it is worth being deliberate about its own settings because timing every node has a measurable cost of its own.

Together the two answer different halves of the same question, and query plan regression covers using them to catch a plan changing rather than to investigate after somebody complains.