select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / REPORTING AND LOGGING

log_min_duration_sample

Read PG 18 manual ↗

Allows sampling the duration of completed statements that ran for at least the specified amount of time.

Type
integer
Context
superuser
Measured default
-1 ms
Unit
ms
Metadata snapshot
18

Definition PG 18 manual

Allows sampling the duration of completed statements that ran for at least the specified amount of time. This produces the same kind of log entries as log_min_duration_statement, but only for a subset of the executed statements, with sample rate controlled by log_statement_sample_rate. For example, if you set it to 100ms then all SQL statements that run 100ms or longer will be considered for sampling. Enabling this parameter can be helpful when the traffic is too high to log all queries. If this value is specified without units, it is taken as milliseconds. Setting this to zero samples all statement durations. -1 (the default) disables sampling statement durations. Only superusers and users with the appropriate SET privilege can change this setting.

This setting has lower priority than log_min_duration_statement, meaning that statements with durations exceeding log_min_duration_statement are not subject to sampling and are always logged.

Other notes for log_min_duration_statement apply also to this setting.

Measured default history
Version intervalDefault
13 – 19-1 ms
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

log_min_duration_sample admits completed statements at or above its duration threshold into stochastic logging controlled by log_statement_sample_rate. -1 disables this path, zero admits every completed statement, and the sample rate then decides which admitted statements are emitted.

log_min_duration_statement has higher priority. A statement that reaches its threshold is always logged and is not sampled, even if it also exceeds log_min_duration_sample. Under the extended query protocol, Parse, Bind, and Execute durations are logged separately.

It is a SUPERUSER-context session setting. Sampled entries have the same statement-text, Bind-value, correlation, overhead, and security considerations as log_min_duration_statement, so log_line_prefix and log_parameter_max_length still determine usefulness and exposure.

Operational considerations

Expecting sampling to affect statements already captured by the higher-priority log_min_duration_statement threshold.

Forgetting that Parse, Bind, and Execute are timed and logged separately with the extended query protocol.

Setting zero with log_statement_sample_rate = 1 and unintentionally logging every completed statement duration.

Sampling SQL and Bind values without correlation identifiers, redaction, access control, and a measured volume budget.

Workload guidance

OLAP: Long analytical queries often exceed the always-log threshold, so sampling may provide no reduction for them. Choose thresholds from the duration distribution rather than copying OLTP values.

OLTP: Set an always-log threshold first with log_min_duration_statement, then use a lower sample threshold and measured rate for the high-volume middle band. Verify actual sample counts and sensitive-data handling under peak OLTP traffic.

SMALL: Use a conservative rate and bounded statement text. A small node should avoid zero with rate 1 unless it intentionally wants every statement-duration entry.

Version history 3
  1. PG 17 → 18changed
  2. PG 14 → 15changed
  3. PG 12 → 13added

Related entries

Further reading

Definition snapshot: english-manuals:2694d9eb8a0b1cbe37723c086eb… · English manual source