log_statement_sample_rate

Definition PG 18 manual

Determines the fraction of statements with duration exceeding log_min_duration_sample that will be logged. Sampling is stochastic, for example 0.5 means there is statistically one chance in two that any given statement will be logged. The default is 1.0, meaning to log all sampled statements. Setting this to zero disables sampled statement-duration logging, the same as setting log_min_duration_sample to -1. Only superusers and users with the appropriate SET privilege can change this setting.

How it works

log_statement_sample_rate sets the fraction of statements exceeding "log_min_duration_sample" to be logged. Use a value between 0.0 (never log) and 1.0 (always log). This probability is evaluated only for statements admitted by log_min_duration_sample; it does not sample log_statement or log_min_duration_statement output.

log_statement_sample_rate is a SUPERUSER-context setting. Superuser or a role granted the appropriate SET privilege can change it for a session, while ALTER ROLE or ALTER DATABASE can establish a default for future sessions.

It changes emitted diagnostic data rather than query semantics, but volume, sensitive content, log_line_prefix, destinations, collector throughput, and retention determine operational cost and usefulness.

Operational considerations

Changing log_statement_sample_rate in one session and assuming role defaults, database defaults, or other pooled sessions changed with it.

Enabling richer logging without budgeting collector throughput, storage, retention, and downstream query cost.

Writing SQL text, bind values, identities, or host data without a redaction and access-control policy.

Expecting it to sample all statement logging even though it only gates log_min_duration_sample.

Workload guidance

OLAP: Analytical jobs can justify richer log_statement_sample_rate telemetry, but account for long statements, large bind values, and bursty completion patterns in the log pipeline.

OLTP: Tune log_statement_sample_rate against an explicit observability question and a measured log-volume budget. Prefer selective thresholds, sampling, or role-level overrides over indiscriminate capture.

SMALL: Keep log_statement_sample_rate useful but bounded: verify disk, collector, retention, and redaction capacity before increasing detail or frequency.