log_min_duration_sample

log_min_duration_sample is the PostgreSQL setting that defines the minimum execution time above which a sample of statements will be logged. Sampling is determined by “log_statement_sample_rate”.

Note

Fact — official short description: “Sets the minimum execution time above which a sample of statements will be logged. Sampling is determined by “log_statement_sample_rate”.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valuesuperuser: Settable at runtime by a superuser
Unit , Valuems: Raw unit
Range , Value-1 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueReporting and Logging / When to Log: Upstream classification
Latest boot value , Value-1: -1 ms

Lifecycle

Fact	Value
First observed	PG13
Present in	PG13–19 Beta 3
Removed in	No
Introduction commit	`6e3e6cc0e884` — Allow sampling of statements depending on duration
Commit date	2019-11-04
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG13–19 Beta 3	`-1`	`ms`	-1 ms

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.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
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.
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.
Small nodes	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.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG13–19 Beta 3 unmodified; OLAP: PG13–19 Beta 3 unmodified; CRIT: PG13–19 Beta 3 unmodified; TINY: PG13–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

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.

log_min_messages · log_min_error_statement · log_min_duration_statement · log_statement_sample_rate · log_transaction_sample_rate