log_min_duration_statement

Definition PG 18 manual

Causes the duration of each completed statement to be logged if the statement ran for at least the specified amount of time. For example, if you set it to 250ms then all SQL statements that run 250ms or longer will be logged. Enabling this parameter can be helpful in tracking down unoptimized queries in your applications. If this value is specified without units, it is taken as milliseconds. Setting this to zero prints all statement durations. -1 (the default) disables logging statement durations. Only superusers and users with the appropriate SET privilege can change this setting.

This overrides log_min_duration_sample, meaning that queries with duration exceeding this setting are not subject to sampling and are always logged.

For clients using extended query protocol, durations of the Parse, Bind, and Execute steps are logged independently.

How it works

The value is a duration in milliseconds when no unit is written. A value of -1 disables duration-based statement logging, zero logs every completed statement, and a positive value logs statements at or above the threshold.

Statements selected by this setting are always logged rather than sampled, so it takes priority over log_min_duration_sample. Under the extended query protocol, Parse, Bind, and Execute durations can appear separately.

This parameter observes and records completed work; it does not stop slow statements. statement_timeout is the separate execution-cancellation control.

Operational considerations

Low thresholds on high-throughput systems can create extreme log volume and I/O.

SQL text can contain sensitive literals and must be protected like application data.

It logs slow statements but does not cancel them; use statement_timeout for that goal.

Extended-protocol phases may be logged separately and need session or PID correlation.

Interactions with log_statement, sampling, and log_line_prefix can confuse duplicate or fragmented entries.

Workload guidance

OLAP: Use a higher threshold so normal long analytical work does not flood logs. Pair logs with query identifiers and workload labels so repeated reports remain actionable.

OLTP: Choose a threshold from the application's latency objective and expected log volume. At high QPS, combine a meaningful hard threshold with sampled logging for the faster population.

SMALL: A low threshold can be useful while tuning, but watch disk use and rotation. Raise it or switch to sampling when logging becomes a measurable part of the workload.