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 interval | Default |
|---|---|
| 13 – 19 | -1 ms |
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
- PG 17 → 18changed
- PG 14 → 15changed
- PG 12 → 13added
Related entries
Further reading
Definition snapshot: english-manuals:2694d9eb8a0b1cbe37723c086eb… · English manual source