{"Entry":{"collection":"guc","key":"vacuum_cost_delay","name":"vacuum_cost_delay","aliases":[],"metadata":{"baseline":false,"boot_human":"Not specified","boot_val":null,"category":"Vacuuming / Cost-Based Vacuum Delay","category_zh":"","changed_in":["12","18"],"changes":[{"documentation_changed":false,"fields":{},"from":"7.4","status":"added","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"8.1","status":"changed","to":"8.2"},{"documentation_changed":true,"fields":{},"from":"8.2","status":"changed","to":"8.3"},{"documentation_changed":true,"fields":{},"from":"8.3","status":"changed","to":"8.4"},{"documentation_changed":true,"fields":{"vartype":{"from":"integer","to":"real"}},"from":"11","status":"changed","to":"12"},{"documentation_changed":true,"fields":{"category":{"from":"Resource Usage / Cost-Based Vacuum Delay","to":"Vacuuming / Cost-Based Vacuum Delay"}},"from":"17","status":"changed","to":"18"}],"content_hash":"1a75a2c6fad93af48c54ea56e9a0993cd496f7ee47784ddde088eff35e17ee40","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"0 ms"}],"editorial":{"advice":{"olap":"During post-load windows, a larger budget or shorter delay can improve maintenance throughput, but verify that scans do not starve queries/imports. Failsafe activation means normal pacing already failed.","oltp":"Tune vacuum_cost_delay from autovacuum duration, dead-tuple growth, and foreground I/O latency together. Prefer per-table overrides for hotspots; global throttling must not let cleanup fall permanently behind.","small":"Keep conservative defaults. On slow disks, lowering concurrency or overriding one table is usually more controllable than making the delay arbitrarily large."},"mechanism":["Vacuum cost delay in milliseconds. It can be changed at session scope, so different sessions may observe different behavior.","VACUUM accumulates virtual cost for page hits, misses, and dirties; after the balance reaches vacuum_cost_limit it sleeps for vacuum_cost_delay and resets. This is coarse I/O pacing rather than an exact bandwidth cap, and the wraparound failsafe bypasses throttling.","Monitor and change vacuum_cost_delay together with vacuum_cost_limit, vacuum_cost_page_hit, vacuum_cost_page_miss. 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":["Changing the global value while a table storage parameter overrides it.","Treating reltuples and cumulative change statistics as exact real-time counts.","Blaming a threshold without checking long transactions, replication slots, and worker saturation.","Buying short-term quiet by deferring maintenance until wraparound failsafe activates."],"references":[{"title":"PostgreSQL 19 Beta 4: vacuum_cost_delay","url":"https://www.postgresql.org/docs/19/runtime-config-vacuum.html#GUC-VACUUM-COST-DELAY"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["vacuum_cost_limit","vacuum_cost_page_hit","vacuum_cost_page_miss","vacuum_cost_page_dirty","autovacuum_vacuum_cost_delay","autovacuum_vacuum_cost_limit"],"summary":"vacuum_cost_delay — Vacuum cost delay in milliseconds. Observed in PG9.0–19 Beta 4; its last measured boot default is 0 ms in PG19 Beta 4, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA."},"enumvals":[],"first_version":"8.0","group":"Vacuuming","group_slug":"vacuum","imported_at":"2026-09-27T17:57:32.266879+08:00","intro_commit":{},"key":"vacuum_cost_delay","last_version":"20","max_val":"","min_val":"","name":"vacuum_cost_delay","position":446,"present_in":["8.0","8.1","8.2","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":"The amount of time that the process will sleep when the cost limit has been exceeded.","short_desc_zh":"","source_rev":"english-manuals:dd5368e0244da8c812e89b0a056f8b2f6ff142aba6f2ea1ad9c8d5d37abb1313","unit":"","vartype":"real"}},"Definition":{"Collection":"guc","Key":"vacuum_cost_delay","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"vacuum_cost_delay","SourceRevision":"english-manuals:dd5368e0244da8c812e89b0a056f8b2f6ff142aba6f2ea1ad9c8d5d37abb1313","Facts":{"boot_val":"0","category":"Vacuuming / Cost-Based Vacuum Delay","context":"user","description":"The amount of time that the process will sleep when the cost limit has been exceeded. If this value is specified without units, it is taken as milliseconds. The default value is 0, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. When using cost-based vacuuming, appropriate values for vacuum_cost_delay are usually quite small, perhaps less than 1 millisecond. While vacuum_cost_delay can be set to fractional-millisecond values, such delays may not be measured accurately on older platforms. On such platforms, increasing VACUUM's throttled resource consumption above what you get at 1ms will require changing the other vacuum cost parameters. You should, nonetheless, keep vacuum_cost_delay as small as your platform will consistently measure; large delays are not helpful.","doc":{"anchor":"GUC-VACUUM-COST-DELAY","file":"runtime-config-vacuum.html","lang":"en","sha256":"7047f1fa9138b97f1812532f8a905fa7479451dfd64655e029a7d387b20b22e4","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"100","metadata_version":"18","min_val":"0","name":"vacuum_cost_delay","short_desc":"Vacuum cost delay in milliseconds.","source":"pg-settings-source-snapshot","unit":"ms","vartype":"real"},"ManualEvidence":{"doc":{"anchor":"GUC-VACUUM-COST-DELAY","file":"runtime-config-vacuum.html","lang":"en","sha256":"7047f1fa9138b97f1812532f8a905fa7479451dfd64655e029a7d387b20b22e4","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"vacuum_cost_delay","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"vacuum_cost_delay","Summary":"","BodyHTML":"\u003cp\u003e超过代价上限后，进程将休眠的时长。如果未指定单位，则以毫秒为单位。默认值为 \u003ccode\u003e0\u003c/code\u003e，表示禁用基于代价的清理延迟功能。正值会启用基于代价的清理。\u003c/p\u003e\u003cp\u003e使用基于代价的清理时，\u003ccode\u003evacuum_cost_delay\u003c/code\u003e 的合适值通常很小，可能不到 1 毫秒。虽然 \u003ccode\u003evacuum_cost_delay\u003c/code\u003e 可以设为以毫秒为单位的小数值，但较旧的平台可能无法准确计量这种延迟。在这些平台上，若要让 \u003ccode\u003eVACUUM\u003c/code\u003e 的资源用量超过延迟设为 1ms 时的水平，需要调整其他清理代价参数。尽管如此，仍应将 \u003ccode\u003evacuum_cost_delay\u003c/code\u003e 设为平台能够稳定计量的尽可能小的值；较大的延迟没有帮助。\u003c/p\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"68ffdaef4c56e8b261ac41a8fca5ae73e6d3495ffb80559c78f48a4395686b97","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e超过代价上限后，进程将休眠的时长。如果未指定单位，则以毫秒为单位。默认值为 \u003ccode class=\"literal\"\u003e0\u003c/code\u003e，表示禁用基于代价的清理延迟功能。正值会启用基于代价的清理。\u003c/p\u003e\u003cp\u003e使用基于代价的清理时，\u003ccode class=\"varname\"\u003evacuum_cost_delay\u003c/code\u003e 的合适值通常很小，可能不到 1 毫秒。虽然 \u003ccode class=\"varname\"\u003evacuum_cost_delay\u003c/code\u003e 可以设为以毫秒为单位的小数值，但较旧的平台可能无法准确计量这种延迟。在这些平台上，若要让 \u003ccode class=\"command\"\u003eVACUUM\u003c/code\u003e 的资源用量超过延迟设为 1ms 时的水平，需要调整其他清理代价参数。尽管如此，仍应将 \u003ccode class=\"varname\"\u003evacuum_cost_delay\u003c/code\u003e 设为平台能够稳定计量的尽可能小的值；较大的延迟没有帮助。\u003c/p\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","8.0","8.1","8.2","8.3","8.4","9.0","9.1","9.2","9.3","9.4","9.5","9.6"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}