タイプ: | 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.
On 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?
On 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