{"Entry":{"collection":"guc","key":"random_page_cost","name":"random_page_cost","aliases":[],"metadata":{"baseline":true,"boot_human":"Not specified","boot_val":null,"category":"Query Tuning / Planner Cost Constants","category_zh":"","changed_in":[],"changes":[{"documentation_changed":true,"fields":{},"from":"7.4","status":"changed","to":"8.0"},{"documentation_changed":true,"fields":{},"from":"8.1","status":"changed","to":"8.2"},{"documentation_changed":true,"fields":{},"from":"8.4","status":"changed","to":"9.0"},{"documentation_changed":true,"fields":{},"from":"9.1","status":"changed","to":"9.2"},{"documentation_changed":true,"fields":{},"from":"9.3","status":"changed","to":"9.4"},{"documentation_changed":true,"fields":{},"from":"9.4","status":"changed","to":"9.5"},{"documentation_changed":true,"fields":{},"from":"9.6","status":"changed","to":"10"},{"documentation_changed":true,"fields":{},"from":"12","status":"changed","to":"13"}],"content_hash":"a2ea591d25defc5ee7125655fff29683c023fe3d95cbf657d36eb4d39c43e7fe","context":"","default_changed_in":[],"default_history":[{"from":"9.0","to":"19","value":"4"}],"editorial":{"advice":{"olap":"Do not lower it merely because storage is SSD; analytical scans may still favor sequential access. Calibrate with the full scan-versus-index workload mix and consider tablespace-specific values.","oltp":"On low-latency SSD with a high cache hit rate, 1.1 is a reasonable trial value, not a universal truth. Compare representative EXPLAIN (ANALYZE, BUFFERS) plans and tail latency before adopting it.","small":"If the entire database is usually cached, a value near seq_page_cost can be defensible. Avoid setting it below seq_page_cost and fix stale statistics before forcing index-heavy plans."},"mechanism":["Planner cost units are arbitrary and meaningful mainly in relation to other cost constants. With seq_page_cost conventionally at 1.0, random_page_cost expresses the average penalty of random page access after accounting for expected caching and storage behavior.","Reducing the value relative to seq_page_cost favors index scans; increasing it makes such scans less attractive. Both values can also be overridden per tablespace, which is useful when a cluster spans storage tiers.","The official guidance treats these constants as workload-wide averages and warns against changing them from a few isolated experiments. Plan quality also depends on statistics, effective_cache_size, correlation, and query shape."],"pitfalls":["The number is a relative planner cost, not milliseconds or measured device latency.","Lowering it to repair one query can regress the wider workload.","Bad cardinality estimates can be mistaken for incorrect storage costs.","A value below seq_page_cost is normally physically implausible.","A global value can misrepresent mixed SSD, HDD, and network-attached tablespaces."],"references":[{"title":"PostgreSQL 19 Beta 4: random_page_cost","url":"https://www.postgresql.org/docs/19/runtime-config-query.html#GUC-RANDOM-PAGE-COST"},{"title":"PostgreSQL 18: Using EXPLAIN","url":"https://www.postgresql.org/docs/18/using-explain.html"},{"title":"PostgreSQL 19 release notes","url":"https://www.postgresql.org/docs/19/release-19.html"}],"related":["seq_page_cost","effective_cache_size","effective_io_concurrency","default_statistics_target","enable_indexscan","enable_bitmapscan"],"summary":"A planner cost constant describing non-sequential page access relative to sequential access. Lowering it makes index and bitmap access paths look cheaper; it does not change storage behavior itself."},"enumvals":[],"first_version":"7.4","group":"Query Tuning","group_slug":"query","imported_at":"2026-09-27T17:57:31.8558+08:00","intro_commit":{},"key":"random_page_cost","last_version":"20","max_val":"","min_val":"","name":"random_page_cost","position":320,"present_in":["7.4","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":"Sets the planner's estimate of the cost of a non-sequentially-fetched disk page.","short_desc_zh":"","source_rev":"english-manuals:8a3607d63af5b29cd13b2d4a2f2c03493b287df378ffdb4ead12643b71dfbd24","unit":"","vartype":"real"}},"Definition":{"Collection":"guc","Key":"random_page_cost","SourceDatabase":"center","Version":"18","SourceTable":"guc","SourceKey":"random_page_cost","SourceRevision":"english-manuals:8a3607d63af5b29cd13b2d4a2f2c03493b287df378ffdb4ead12643b71dfbd24","Facts":{"boot_val":"4","category":"Query Tuning / Planner Cost Constants","context":"user","description":"Sets the planner's estimate of the cost of a non-sequentially-fetched disk page. The default is 4.0. This value can be overridden for tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see ALTER TABLESPACE). Reducing this value relative to seq_page_cost will cause the system to prefer index scans; raising it will make index scans look relatively more expensive. You can raise or lower both values together to change the importance of disk I/O costs relative to CPU costs, which are described by the following parameters. Random access to durable storage is normally much more expensive than four times sequential access. However, a lower default is used (4.0) because the majority of random accesses to storage, such as indexed reads, are assumed to be in cache. Also, the latency of network-attached storage tends to reduce the relative overhead of random access. If you believe caching is less frequent than the default value reflects, and network latency is minimal, you can increase random_page_cost to better reflect the true cost of random storage reads. Storage that has a higher random read cost relative to sequential, like magnetic disks, might also be better modeled with a higher value for random_page_cost. Correspondingly, if your data is likely to be completely in cache, such as when the database is smaller than the total server memory, or network latency is high, decreasing random_page_cost might be appropriate. Tip Although the system will let you set random_page_cost to less than seq_page_cost, it is not physically sensible to do so. However, setting them equal makes sense if the database is entirely cached in RAM, since in that case there is no penalty for touching pages out of sequence. Also, in a heavily-cached database you should lower both values relative to the CPU parameters, since the cost of fetching a page already in RAM is much smaller than it would normally be.","doc":{"anchor":"GUC-RANDOM-PAGE-COST","file":"runtime-config-query.html","lang":"en","sha256":"33456ca7ef52bf28e93e34b932a411db7a1b95800179add2cf867dc6ec9144bc","slug":"18"},"documented":true,"enumvals":null,"extra_desc":null,"lang":"en","max_val":"1.79769e+308","metadata_version":"18","min_val":"0","name":"random_page_cost","short_desc":"Sets the planner's estimate of the cost of a nonsequentially fetched disk page.","source":"pg-settings-source-snapshot","unit":null,"vartype":"real"},"ManualEvidence":{"doc":{"anchor":"GUC-RANDOM-PAGE-COST","file":"runtime-config-query.html","lang":"en","sha256":"33456ca7ef52bf28e93e34b932a411db7a1b95800179add2cf867dc6ec9144bc","slug":"18"}},"MeasuredEvidence":{"metadata_version":"18"}},"Text":{"Collection":"guc","Key":"random_page_cost","SourceDatabase":"pgweb","Version":"18","Locale":"zh-Hans","Title":"random_page_cost","Summary":"","BodyHTML":"\u003cp\u003e设置规划器对一次非顺序磁盘页面读取的代价估计。默认值是 4.0。对于某个表空间内的表和索引，可以通过设置该表空间的同名参数来覆盖此值（见\u003ca href=\"/docs/18/sql-altertablespace.html\" title=\"ALTER TABLESPACE\" rel=\"nofollow\"\u003e\u003cspan\u003eALTER TABLESPACE\u003c/span\u003e\u003c/a\u003e）。\u003c/p\u003e\u003cp\u003e减少这个值（相对于\u003ccode\u003eseq_page_cost\u003c/code\u003e）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。\u003c/p\u003e\u003cp\u003e对持久存储的随机访问通常远不止比顺序访问贵四倍。不过，仍使用较低的默认值（4.0），因为假定对存储的大多数随机访问（例如索引读取）都将在缓存中命中。此外，网络附加存储的延迟往往会降低随机访问的相对额外开销。\u003c/p\u003e\u003cp\u003e如果你认为缓存命中的频率低于默认值所反映的情况，并且网络延迟很低，则可以增大 random_page_cost，以更好地反映随机存储读取的真实代价。若某种存储的随机读取代价相对于顺序读取更高，例如机械磁盘，也可以用更高的 random_page_cost 值来更好地建模。对应地，如果你的数据很可能完全缓存在内存中，例如数据库小于服务器总内存，或者网络延迟较高，则降低 random_page_cost 可能更合适。\u003c/p\u003e\u003cdiv\u003e\n提示\u003cp\u003e尽管系统允许将\u003ccode\u003erandom_page_cost\u003c/code\u003e设置得小于\u003ccode\u003eseq_page_cost\u003c/code\u003e，但这不符合实际物理情况。不过，如果数据库完全缓存在 RAM 中，将它们设置为相等是合理的，因为此时非顺序访问页面不会产生额外代价。同样，对于大部分数据已缓存的数据库，应相对于 CPU 参数降低这两个值，因为读取一个已在 RAM 中的页面的代价远小于通常的页面读取代价。\u003c/p\u003e\u003c/div\u003e","SourceRevision":"2026-09-11@29c86d9","ContentHash":"c15ed60148a3c81c88f502a0c7b7294d16b058865ad03f66cfeabbe4df790ebd","Payload":{"carried_from":"","carry_reason":"","doc_html":"\u003cp\u003e设置规划器对一次非顺序磁盘页面读取的代价估计。默认值是 4.0。对于某个表空间内的表和索引，可以通过设置该表空间的同名参数来覆盖此值（见\u003ca href=\"/docs/18/sql-altertablespace.html\" title=\"ALTER TABLESPACE\"\u003e\u003cspan class=\"refentrytitle\"\u003eALTER TABLESPACE\u003c/span\u003e\u003c/a\u003e）。\u003c/p\u003e\u003cp\u003e减少这个值（相对于\u003ccode class=\"varname\"\u003eseq_page_cost\u003c/code\u003e）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。\u003c/p\u003e\u003cp\u003e对持久存储的随机访问通常远不止比顺序访问贵四倍。不过，仍使用较低的默认值（4.0），因为假定对存储的大多数随机访问（例如索引读取）都将在缓存中命中。此外，网络附加存储的延迟往往会降低随机访问的相对额外开销。\u003c/p\u003e\u003cp\u003e如果你认为缓存命中的频率低于默认值所反映的情况，并且网络延迟很低，则可以增大 random_page_cost，以更好地反映随机存储读取的真实代价。若某种存储的随机读取代价相对于顺序读取更高，例如机械磁盘，也可以用更高的 random_page_cost 值来更好地建模。对应地，如果你的数据很可能完全缓存在内存中，例如数据库小于服务器总内存，或者网络延迟较高，则降低 random_page_cost 可能更合适。\u003c/p\u003e\u003cdiv class=\"tip\"\u003e\n提示\u003cp\u003e尽管系统允许将\u003ccode class=\"varname\"\u003erandom_page_cost\u003c/code\u003e设置得小于\u003ccode class=\"varname\"\u003eseq_page_cost\u003c/code\u003e，但这不符合实际物理情况。不过，如果数据库完全缓存在 RAM 中，将它们设置为相等是合理的，因为此时非顺序访问页面不会产生额外代价。同样，对于大部分数据已缓存的数据库，应相对于 CPU 参数降低这两个值，因为读取一个已在 RAM 中的页面的代价远小于通常的页面读取代价。\u003c/p\u003e\u003c/div\u003e","doc_same_as":""}},"RequestedLocale":"zh-Hans","Fallback":false,"Versions":["10","11","12","13","14","15","16","17","18","19","20","7.4","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}