{"Entry":{"collection":"guc","key":"synchronize_seqscans","name":"synchronize_seqscans","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Version and Platform Compatibility / Previous PostgreSQL Versions","category_zh":"","changed_in":["18"],"changes":[{"documentation_changed":false,"fields":{},"from":"8.2","status":"added","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"9.6","status":"changed","to":"10"},{"documentation_changed":false,"fields":{"short_desc":{"from":"Enable synchronized sequential scans.","to":"Enables synchronized sequential scans."}},"from":"17","status":"changed","to":"18"}],"content_hash":"680bb7e17d0a6490a5eefebbf650173f36e924c2cef9150818a9b13d78a04580","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"on"}],"editorial":{"advice":{"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."},"mechanism":["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."],"pitfalls":["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."],"references":[{"title":"PostgreSQL 19 Beta 4: synchronize_seqscans","url":"https://www.postgresql.org/docs/19/runtime-config-compatible.html#GUC-SYNCHRONIZE-SEQSCANS"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["default_with_oids","lo_compat_privileges","operator_precedence_warning","standard_conforming_strings","array_nulls","backslash_quote"],"summary":"synchronize_seqscans — Enables synchronized sequential scans. Observed in PG9.0–19 Beta 4; its last measured boot default is on in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"8.3","group":"Version and Platform Compatibility","group_slug":"compatible","imported_at":"2026-09-27T17:57:32.090552+08:00","intro_commit":{},"key":"synchronize_seqscans","last_version":"20","max_val":"","min_val":"","name":"synchronize_seqscans","position":397,"present_in":["8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6","10","11","12","13","14","15","16","17","18","19","20"],"short_desc":"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.","short_desc_zh":"","source_rev":"english-manuals:88ba0373c4f0bacb733c6039eaea01b7e794b6bafe7aaa72761def999ebd2e84","unit":"","vartype":"bool"}},"Definition":{"Collection":"guc","Key":"synchronize_seqscans","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"synchronize_seqscans","SourceRevision":"english-manuals:88ba0373c4f0bacb733c6039eaea01b7e794b6bafe7aaa72761def999ebd2e84","Facts":{"boot_val":"on","category":"Version and Platform Compatibility / Previous PostgreSQL Versions","context":"user","description":"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.","doc":{"anchor":"GUC-SYNCHRONIZE-SEQSCANS","file":"runtime-config-compatible.html","lang":"en","sha256":"db2ecac1e62738d66a4932f4c8197976a349bcbf261c5b90fff740bc44867b8b","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":null,"metadata_version":"18","min_val":null,"name":"synchronize_seqscans","short_desc":"Enables synchronized sequential scans.","source":"pg-settings-source-snapshot","unit":null,"vartype":"bool"},"ManualEvidence":{"doc":{"anchor":"GUC-SYNCHRONIZE-SEQSCANS","file":"runtime-config-compatible.html","lang":"en","sha256":"db2ecac1e62738d66a4932f4c8197976a349bcbf261c5b90fff740bc44867b8b","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"synchronize_seqscans","SourceDatabase":"center","Version":"18","Locale":"en","Title":"synchronize_seqscans","Summary":"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.","BodyHTML":"\u003cp\u003eThis 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.\u003c/p\u003e","SourceRevision":"english-manuals:88ba0373c4f0bacb733c6039eaea01b7e794b6bafe7aaa72761def999ebd2e84","ContentHash":"88904c031fd272b28bf9ec5bc8aaee2f01d30e25c6893e2ce2abfd2bea6dac51","Payload":{"description":"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."}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}