synchronize_seqscans

Definition PG 18 manual

This allows sequential scans of large tables to synchronize with each other, so that concurrent scans read the same block at about the same time and hence share the I/O workload. When this is enabled, a scan might start in the middle of the table and then “wrap around” the end to cover all rows, so as to synchronize with the activity of scans already in progress. This can result in unpredictable changes in the row ordering returned by queries that have no ORDER BY clause. Setting this parameter to off ensures the pre-8.3 behavior in which a sequential scan always starts from the beginning of the table. The default is on.

How it works

Enables synchronized sequential scans. It can be changed at session scope, so different sessions may observe different behavior.

Concurrent sequential scans of the same large relation may join a shared scan position, improving cache reuse while returning rows in a less predictable physical order. SQL without ORDER BY has no ordering guarantee regardless of this switch.

Monitor and change synchronize_seqscans together with default_with_oids, lo_compat_privileges, operator_precedence_warning. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Keeping a compatibility switch permanently instead of fixing the client.

Testing in one session and deploying globally to unrelated applications.

Confusing parsing compatibility with data or security compatibility.

Forgetting to remove an override after the upgrade migration is complete.

Workload guidance

OLAP: Analytical concurrency is the most likely beneficiary. Experiment at session scope only when repeatable benchmarks show the shared scan position harms locality.

OLTP: Normally keep it on so concurrent large-table scans can share cache footprint. Queries that require deterministic order must use ORDER BY; disabling this setting is not an ordering contract.

SMALL: Keep the default. When data fits in cache or concurrent scans are rare, this setting usually needs no attention and is not a bottleneck.