PostgreSQL の共通構成パラメータ [1 つのテーブルの説明]

パラメータ	変更には再起動が必要です	説明する	タイプ	デフォルト	範囲	セッティングアドバイス
仕事の記憶		最小 64kB。ソートに使用されるメモリのサイズを制限できます。この値は、クライアントの接続後に増やすことができます。このタイプの割り当てでは「非共有メモリ」が使用されます。	整数	4MB	64~2147483647 KB 単位は通常 64MB に設定されます。	万能の答えを見つけようとする場合、通常は 64MB に設定されます。多くの場合、メモリ内での並べ替えは、ディスク上の一時ファイルを必要とする並べ替えよりもはるかに高速です。このパラメーターを比較的大きな値に設定すると、各ソート操作に大量のメモリーが必要となるため、デプロイメント環境でメモリーがボトルネックになります。したがって、並べ替え操作を実行する必要があるユーザーが多数いる場合、システムはすべてのユーザーに work_mem × total_sort_operations メモリを割り当てます。この値をグローバルに非常に高く設定すると、メモリ使用量が高くなる可能性があります。したがって、今後はこのパラメータをセッション レベルで設定することをお勧めします。
共有バッファ	Y	共有メモリ バッファはパラメータshared_buffersによって設定され、PostgreSQLが使用できるプライベート キャッシュ サイズを決定します。shared_buffers の値を増やすことは、パフォーマンスを向上させるための最も効果的な設定の 1 つです。専用データベース サーバーの場合、shared_buffers はシステム メモリの約 25% に設定できます。PostgreSQL はオペレーティング システムのキャッシュにも依存しているため、メモリの 40% を超える共有バッファはパフォーマンスのヒントにはなりませんが、低下する可能性があります。	整数	1000	16~1073741823 ブロック 各バッファ ブロックは 8KB メモリ 25% è メモリ 40%	すべてのマシンとオペレーティング システムでの互換性を確保するために、PostgreSQL はデフォルトでこの値を小さい値 (通常は 128 MB) に設定します。したがって、shared_buffers の値を増やすことは、パフォーマンスを向上させるための最も効果的な設定の 1 つです。通常、shared_buffers の値を増やすと、チェックポイント間隔を延長するために max_wal_size の値も対応して増やす必要があります。専用データベース サーバーの場合、shared_buffers はシステム メモリの約 25% に設定できます。shared_buffers がメモリの 40% を超えてもパフォーマンスのヒントは得られません。
メンテナンス作業記憶		VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY などの定期的なメンテナンス操作に許可される最大メモリを指定します。	整数	64MB	1024~2147483647KB	データベース セッションでは同時に 1 つのメンテナンス操作のみを実行できるため、通常、同時メンテナンス操作は存在しません。したがって、このパラメータを work_mem よりも大幅に大きく設定しても問題はありません。メンテナンス メモリを増やすと、データベースのクリーニングとデータ インポートも向上します。 .パフォーマンス。唯一の注意点は、autovacuum が有効になっている場合、autovacuum_max_workers (デフォルトでは 3) に work_mem 設定を掛けたものと同じ量のメモリを消費する可能性があることです。これに対して別の autovacuum_work_mem パラメータを設定することもできます。
有効なキャッシュサイズ		単一のクエリに対してプランナが使用できる有効なディスク バッファ サイズを設定します。PostgreSQL に、オペレーティング システムとデータベースで使用できるキャッシュの推定値を提供します。デフォルト値は 4 GB ですが、控えめに見積もってもシステムの使用可能なメモリの 1/2 に設定できます。通常、専用データベース サーバーの合計システム メモリの 75% に設定でき、特定のサーバーのワークロードに応じて調整できます。効果的なキャッシュ サイズの設定が低すぎる場合、インデックスによってクエリのパフォーマンスが大幅に向上する場合でも、クエリ プランナーは特定のインデックスを無視する可能性があります。	整数	4ギガバイト	システムの利用可能なメモリの控えめな 1/2 è 専用データベース サーバーはシステム メモリ全体の 3/4 に設定可能 最小: 1 (8kB) 最大: 2147483647 (17179869176kB) 単位: 8kB	値が単位なしで指定された場合、ブロック単位、つまり BLCKSZ バイト、通常は 8kB になります。デフォルト値は 4GB です。(BLCKSZ が 8kB でない場合、デフォルトでは比例的にスケールされます。) システムの利用可能なメモリの控えめな 1/2 è 専用データベース サーバーはシステム メモリ全体の 75% に設定できます。 PostgreSQL クエリ プランナーに、利用可能な RAM の量を見積もるよう指示します。データのキャッシュ。shared_buffers およびファイルシステム キャッシュに含まれます。この設定は、プランナが合理的なコストを見積もるのに役立ちますが、実際にメモリを割り当てるわけではありません。効果的なキャッシュ サイズの設定が低すぎる場合、インデックスによってクエリのパフォーマンスが大幅に向上する場合でも、クエリ プランナーは特定のインデックスを無視する可能性があります。
最大接続数	Y	max_connections はクライアントの最大同時接続数を決定し、通常のデフォルト値は 100 です。接続が多すぎてデータベースに接続できない場合は、最大接続数を増やすことを検討する必要がある場合があります。ただし、このパラメータを変更する場合は、他のパラメータ (特に work_mem) への影響も考慮する必要があります。これらのパラメータは接続ごとに設定されるため、接続数が増加すると、これらのパラメータのメモリ使用量も増加します。マスター/スレーブ レプリケーションのスレーブ ノードの場合、このパラメータの値はマスター ノードの値以上に設定する必要があります。それ以外の場合、スレーブ ノードはクエリ操作を実行できません。	整数	100	100 300 500～700 指定範囲：1～262143	接続が多すぎてデータベースに接続できない場合は、最大接続数を増やすことを検討する必要がある場合があります。このパラメータを変更する場合は、他のパラメータ (特に work_mem) への影響も考慮する必要があります。これらは接続ごとに設定される値であるため、接続数が増加すると、これらのメモリ使用量も増加します。同時接続数が 300 ～ 500 の場合に最高のパフォーマンスが得られます。700 を超えると、パフォーマンスが大幅に低下します (1 秒あたりのトランザクション数とレイテンシの観点から)。接続が 1000 を超えるとパフォーマンスが低下し、遅延が増加します。Google Cloud や Heroku などのクラウド プラットフォームでも、max_connections は約 500 に制限されます。max_connctions は大きすぎるのはよくありません。ローカル メモリ、特に work_mem を推奨します。300 ～ 700 の範囲の値を推奨します。どんなにパフォーマンスが高くても、損失は明らかです。高スループットのデータベースの場合、アプリケーション レベルで組み込み接続プールの使用を検討することも、アプリケーションとデータベースの間で接続プール (pgbouncer など) を使用することもできます。
月光		遺伝的クエリの最適化を有効または無効にします。デフォルトでは有効になっています。通常、運用環境ではこれをオフにしないことが最善です。geqo_threshold 変数は、GEQO のより詳細な null 値を提供します。	ブール値	の上	オンオフ	通常、運用環境ではこれをオフにしないことが最善です。
ランダムページコスト		减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性，后者由下列参数描述。对磁盘存储的随机访问通常比顺序访问要贵不止四倍。但是，由于对磁盘的大部分随机访问（例如被索引的读取）都被假定在高速缓冲中进行，所以使用了一个较低的默认值（4.0）。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍，而期望 90% 的随机读取会被缓存。如果你相信 90% 的缓冲率对你的负载是一个不正确的假设，你可以增加 random_page_cost 来更好的反映随机存储读取的真正代价。相应地，如果你的数据可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的。为具有很低的随机读取代价的存储（例如固态驱动器）采用较低的 random_page_cost 值可能更好。虽然允许你将random_page_cost设置的比 seq_page_cost小，但是物理上的实际情况并不受此影响。 然而当所有数据库都位于内存中时，两者设置为相等是非常合理的，因为 在此情况下，乱序抓取并不比顺序抓取开销更大。同样，在缓冲率很高的 数据库上，你应当相对于 CPU 开销同时降低这两个值，因为获取内存中 的页比通常情况下的开销小许多。	浮点型	4.0	0è1.79769e+308	设置数据库存储的寻道扫描时间的比例。不应该被改变，除非你使用特殊的存储(ssd，高端san等)，其中查找/扫描比率实际上是不同的。如果需要数据库更喜欢索引，那么就调优effecve_cache_size和一些cpu_*开销。 减少这个值（相对于seq_page_cost）将导致系统更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。 若90% 的缓冲率对你的负载是一个不正确的假设，可以增加random_page_cost 来更好的反映随机存储读取的真正代价。 如果数据可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的。
Checkpoint_timeout		影响系统何时启动一个检查点操作。如果现在的时间减去上次检查点操作结束的时间超过了checkpoint_timeout的值，系统就会自动启动一个检查点操作。增大这个参数会增加数据库崩溃以后恢复操作需要的时间。当促发检查点操作时， 数据库会进行前面说的（刷脏数据）行为。这是一个代价十分大的操作，因为它会引发大量的IO。这个过程涉及到了大量读写磁盘的操作。若用户的系统速度赶不上写数据的速度,则可以适当提高该值。	浮点型	5min	53060min~24h可取范围在 30秒到 1 天之间。	增大这个参数会增加数据库崩溃以后恢复操作需要的时间。若用户的系统速度赶不上写数据的速度,则可以适当提高该值。一般来说，默认值（5分钟）相当低,普遍采用30分钟到1小时之间,PostgreSQL 9.6甚至增加了最多1天,建议使用30分钟。如果您执行非常大的ETL批处理，您可能希望将此设置增加到批处理运行的最大长度。
temp_buffers		设置每个数据库会话使用的临时缓冲区的最大数目。此本地缓冲区只用于访问临时表。临时缓冲区是在某个连接会话的服务进程中分配的，属于本地内存。临时缓冲区的大小也是按数据块大小分配的，默认是 1000，对于 8K 的数据块大小为 8MB。	整型	8MB	100~1073741823 单位8KB	此本地缓冲区只用于访问临时表临时缓冲区是在某个连接会话的服务进程中分配的，属于本地内存。目前仅用于在内存中保存临时表。如果您的应用程序需要大量使用临时表(许多专有报表引擎都需要)，那么可能需要大幅增加临时表的使用。但是，要小心，因为这是每个会话分配的非共享RAM。否则，默认即可。
cpu_tuple_cost		设置规划器对一次查询中处理每一行的代价估计。默认值是 0.01	浮点型	0.01	0è 1.79769e+308
deadlock_timeout		在检查是否存在 deadlock 条件之前，等待一个 lock 的时间长度。 死锁检查是相对昂贵的，因此，pg 不会在每次等待 lock 时都运行死锁检测。PostgreSQL 会乐观的认为死锁在生产应用程序中并不常见，只需要等待一段时间后再检查死锁。这是您在实践中想要设置的最小值，在负载很重的 pg 中，可能需要提高本参数值。在理想情况下，本参数值应该超过典型的 transaction 时间，以提高在 PostgreSQL 决定检查死锁之前将释放锁的几率。仅仅 superuser 可以修改本参数值。 在log_lock_waits 参数启用的情况下，deadlock_timeout参数值也决定了一个有关 lock wait 的 log message 被写入运行日志之前的等待时间。如果你正在尝试调查锁定延迟 (lockingdelays)，你可能希望设置比正常deadlock_timeout 参数值更短的时间。	整型	1000ms	应该超过典型的 transaction 时间， 1è2147483647ms	负载很重的 pg 中，可能需要提高本参数值。 在理想情况下，本参数值应该超过典型的 transaction 时间，以提高在 PostgreSQL 决定检查死锁之前将释放锁的几率。 如果你正在尝试调查锁定延迟 (locking delays)，你可能希望设置比正常 deadlock_timeout 参数值更短的时间。
cpu_operator_cost		设置规划器对于一次查询中处理每个操作符或函数的代价估计。默认值是 0.0025。	浮点型	0.0025	0è 1.79769e+308	稍微减少这个值，让数据库更喜欢索引。
stats_start_collector		要想让统计收集器运行起来，参数 stats_start_collector 必须设置为 true ，如果你对统计信息不感兴趣并且想把所有额外的开销都去除，那么可以把它设置为 false	布尔型	TRUE	true/false	如果对统计信息不感兴趣并且想把所有额外的开销都去除，那么可以把它设置为 false
cpu_index_tuple_cost		设置规划器对一次索引扫描中处理每一个索引项的代价估计。默认值是 0.005。	浮点型	0.005	0è 1.79769e+308	稍微减少这个值，让数据库更喜欢索引。
Fsync		将数据刷新到磁盘以确保崩溃安全(关闭此功能可能导致不可恢复的数据损坏) 。强制把数据同步更新到磁盘是因为系统的IO压力很大，为了更好的测试其他配置的影响，把改参数改为off	布尔型	on	on/off	为了更好的测试其他配置的影响，把改参数改为off 将数据刷新到磁盘以确保崩溃安全(关闭此功能可能导致不可恢复的数据损坏) 。