类型: | integer |
默认: | 1024 (8MB) |
最低限度: | 0 (0kB) |
最大: | 715827882 (5726623056kB) |
单元: | 8kB |
上下文: | user |
重新开始: | false |
以来: | 10 |
为必须扫描的表数据量设置一个最小值,扫描的表数据量超过这一个值才会考虑使用并行扫描。 对于并行顺序扫描,被扫描的表数据量总是等于表的尺寸,但是在使用索引时,被扫描的表数据量通常会更小。 如果指定值时没有单位,则以块为单位,即BLCKSZ
字节,通常为8kB。默认值是8兆字节(8MB
)。
建议 [EN]
… , unless doing IoT or a read-only database. Raise to 100MB or so if your traffic on the database is very bursty, to prevent the WAL from shrinking too much.
在 StackOverflow
- Nested Loop Left Join cost too much time?
- Postgresql going mad
- Osm2pgsql extremely slow on import on server with 192GB RAM
- Geoserver WFS + PostgreSQL with large table impossibly slow
- Why does "explain analyzing" this query fnish fast (showing a parallel plan), while running the actual query without "explain analyze" doesn't?
在 pgsql-hackers
- [sqlsmith] parallel worker errors "subplan ... was not initialized"
- Re: pgstat_report_activity() and parallel CREATE INDEX (was: Parallel index creation & pg_stat_activity)
- Reigning in ExecParallelHashRepartitionFirst
- Re: Fix for parallel BTree initialization bug
- Re: v13: CLUSTER segv with wal_level=minimal and parallel index creation