Tuning Your PostgreSQL Server/ja

作者 Greg Smith、Robert Treat、およびChristopher Browne

PostgreSQLは性能よりも幅広い互換性を目的に設定された、基本設定で配布されています。デフォルトのパラメータでは、使用中のシステムを過小評価してしまう可能性が高いです。最終的に把握しなければならない項目のすべて（必要ならばGUC Three Hour Tourを参照してください）に引きずり込まれないように、ここで基本を簡単に紹介することでお助けしようと思います。これらはPostgreSQLの初心者は気にしない、もっとも一般的なもののようです。ここで紹介した概要を読んだ後により詳しく知りたければ、各節にてパラメータの名前をクリックしてください。最新のPostgreSQLのマニュアルの関連文書にリンクしています。さらにServer Configuration Tuningには、これらのパラメータと変更すべきでないパラメータに関する情報が記載されています。

設定に関する背景

PostgreSQLの設定は多くの異なる方法で設定することができます。しかし普通はpostgresql.confファイルで設定することになるでしょう。固有のオプションはリリースごとに異なります。使用中のPostgreSQLのsrc/backend/utils/misc/guc.cというソースコードに利用可能なリストがあります。（しかし普通はpg_settingsビューを参照することで十分だと思います。）

設定の種類

複数の種類の設定があります。取り得る入力に基づいて分類すると以下のようになります。

論理値 true、false、on、off
整数整数 (2112)
浮動小数点 10進の値 (21.12)
メモリ・ディスク整数 (2112)または"コンピュータ向けの単位" (512MB, 2112GB)。整数は避けてください。その意味を把握するには隠されている単位を知らなければなりません。コンピュータ用の単位は8.2以降で利用可能です。
時間 d,m,sとしても知られる時間単位。まれに単位を持たないものがり、省くことがあります。(30s)
文字列単一引用符で括られたテキスト ('pg_log')
列挙特定のリストにある文字列('WARNING', 'ERROR')。
リストカンマで区切られた文字列('"$user",public,tsearch2)。

影響を与えるタイミング

PostgreSQLの設定を変更できるタイミングは、内部コードの制限に関連しますが、柔軟であり、複数のレベルがあります。以下にレベルの全一覧を示します。

Postmaster:サーバの再起動が必要
ハングアップ:サーバのHUPが必要。kill -HUP (通常-1)、pg_ctl reload、またはselect pg_reload_conf();
ユーザ:個々のセッションで設定することが可能。そのセッション内のみで効果あり。
内部: コンパイル時に設定。変更不可。主に参照用
バックエンド: セッション開始前に設定しなければならない設定
スーパーユーザ: スーパーユーザによりサーバ実行時に設定可能

ほとんどの場合最初のもののみを使用することになるでしょう。しかし、サーバを停止させたくない場合2番目のものも有用です。一方ユーザセッションも特殊な場合に有用になることがあります。 pg_settingsビューの"context"フィールドを参照することで、パラメータの設定種類を知ることができます。

postgresql.confに関する重要な注意事項

$PGDATA/postgresql.confとして存在することがわかるはずですが、シンボリックリンクなどになっていないか注意してください。
ファイルの場所はSHOW config_fileを使って見つけ出すことができます。
#から始まる行はコメントで何も影響を与えません。新しいデータベースではこれは、この設定項目はデフォルトを使用していることを意味しますが、実行中のシステムではこれは正しいとは限りません。バージョン8.3より前では設定項目をコメントアウトしてもデフォルトには戻りません。以降のバージョンであってもpostgresql.confへの変更はreload/restartを行わないと影響を与えません。つまりこのファイルに書いてある内容と多少異なる状態でシステムがシステムが稼働していることはあり得ます。
同じ設定項目が複数行書いてあると、最後のものが使われます。

現行の設定の閲覧

postgresql.confを参照します。うまく管理されているものであればこれは動作します、が決定的なものではありません。
show all、show <setting>は設定の現在値を表示します。セッション固有の変更が含まれることに注意してください。
select * from pg_settingsではセッション固有の変更にローカルな変更というラベルが付きます。

listen_addresses

デフォルトではPostgreSQLはローカルホストからの接続のみに応答します。サーバを他のシステムからTCP/IPネットワーク経由でアクセスできるようにしたい場合、listen_addressesをデフォルトから変更する必要があります。よくある方法は以下のようにすべてのアドレスへのアクセスを許可するように設定することです。

listen_addresses = '*'

そしてpg_hba.confを使って接続許可、不許可を制御してください。

max_connections

max_connectionsは名前そのもの、つまり、許されるクライアント接続の最大数を設定します。クライアント単位で割り当てられる、または割り当てられる可能性があるメモリリソースが何かしら存在するため、これは以下のパラメータの一部（特にwork_mem）で非常に重要です。このためクライアントの最大数が最大想定メモリ使用量を暗黙的に示します。一般的には、高性能なハードウェア上のPostgreSQLでは数100接続をサポートすることができます。数1000の接続を受け付けたければ、接続のオーバーヘッドを低減させるためにconnection pooling softwareの使用を検討すべきです。

shared_buffers

shared_buffers設定パラメータはPostgreSQLのデータキャッシュに割り当てられるメモリ量を決定するものです。一部のプラットフォーム（古めのバージョンのSolarisやSGI）ではより大きな値を持たせるためにカーネルのコンパイルなどの出過ぎた作業が必要になることが、デフォルトは低く設定されている１つの理由です。最近のLinuxシステムであっても、標準的なカーネルではまずカーネル設定の調整を行わないと、32MBより大きいshared_buffersを設定することができないことがよくあります。

1GB以上のRAMを持つシステムであれば、shared_buffersの理想的な開始値はシステムメモリの1/4です。システムメモリがこれより小さい場合、OSが使用するメモリ量を注意して考えなければなりません。典型的には15%近くがOSに使用されています。 shared_buffersをもっと大きな値に設定することが効率的な作業量もいくつかありますが、PostgreSQLは同時にオペレーティングシステムのキャッシュにも依存しています。メモリの40%以上を使用することがより少ない量を使用することよりうまく動作することが分かることはあまりありません。

Windows（かつ8.1以前のバージョンのPostgreSQL）において、shared_buffersの値を大きくしても効率的でないことに注意してください。相対的に低く設定し、OSキャッシュを代わりにより多く使用することでより良い結果となることが分かります。 Windowsでは有用な範囲は64MBから512MBであり、8.1より以前のバージョンでは実質の上限はshared_buffers=50000近辺（400MB弱。8.2より以前のバージョンではMB単位で値を設定することができませんので、このパラメータを8Kブロック単位で指定します。）

shared_buffersの値をある大きさまで設定するためにオペレーティングシステムが割り当て可能なメモリ量を増加させなければならないことはよくあります。 Unixシステムでは、サポートしている以上の値に設定すると、以下のようなメッセージが現れます。

IpcMemoryCreate: shmget(key=5432001, size=415776768, 03600) failed: Invalid argument 

このエラーは通常、PostgreSQLの共有メモリセグメントに対する要求がカーネルのSHMMAXパラメータを超えたことを意味します。
要求サイズを小さくすることもできますし、SHMMAXを多くするようにカーネルを再構成することもできます。
要求サイズ（現在415776768バイト）を減らすためには、PostgreSQLのshared_buffersパラメータ（現在50000）、max_connectionsパラメータ（現在12）、またはその両方を小さくしてください。

この問題の詳細についてはManaging Kernel Resourcesを参照してください。

この設定を変更するためにはデータベースの再起動が必要です。また、これはメモリを固定で割り当てます。データベースの起動時に仮想メモリからの割り当て全体を入手します。

effective_cache_size

effective_cache_sizeは、オペレーティングシステム自体と他のアプリケーションが使用するメモリを考慮した後に、OSおよびデータベース自体の内部でディスクキャッシュとして利用可能なメモリ量の推定値に設定されなければなりません。これはOSとPostgreSQLのバッファキャッシュ内で利用可能と推定するメモリ量についての基準であり、割り当てではありません。この値はPostgreSQL問い合わせプランナが生成した計画の内いずれがメモリに合うかどうかを推定するためだけに使用されます。この設定が小さすぎると、インデックスの利用を想定している問い合わせを実行する時に、インデックスが使用されない可能性があります。 shared_buffersの設定はここでは考慮されません。効率的なcache_size_valueのみです。データベースに戦友されるメモリを含めなければなりません。

effective_cache_sizeを全メモリの1/2に設定することが通常の保守的な設定です。メモリの3/4はより積極的ですが、まだ合理的な値です。オペレーティングシステムの統計情報を参照することでより良い推定を行うことができます。 Unix互換のシステムでは、推定値を得るためにfreeまたはtopコマンドのfree+cached数を加えてください。 WindowsではWindowsタスクマネージャのパフォーマンスタブにある"システムキャッシュ"を見てください。この設定の変更はデータベースの再起動を必要としません（HUPで十分です）。

checkpoint_segments checkpoint_completion_target

PostgreSQLはデータベースにおける新しいトランザクションをWALセグメントという名前の16MBサイズのファイルに書き出します。 checkpoint_segments個のファイルが書き出される度（デフォルトは3）に、チェックポイントが発生します。チェックポイントはリソースを激しく消費することがあり得ます。最近のシステムでは48MBごとにこれを行うと、性能上深刻なボトルネックとなります。 checkpoint_segmentsをより大きく設定することでこれを改善することができます。非常に小規模な設定で実行していない限り、最低10に設定することで確実に改善されます。これにより通常目標の完成度を増大させます。

書き込みが激しいシステムでは32（512MBごとのチェックポイント）から256（128Gごとのチェックポイント）が最近よく使われます。非常に大きく設定すると多くのディスクを使用することになり、データベースのリカバリの際に時間がかかるようになります。このため、大きく設定する前にこれらに問題がないことを確認してください。通常大きな値（(>64/1GB)）に設定することはバルクロードでのみ使用されます。このセグメントをどのように選択したとしても、checkpoint_timeoutを増やしていなければ（ほとんどのシステムで不要です）、少なくとも5分おきにチェックポイントが発生することに注意してください。

PostgreSQL 8.3 and newer

PostgreSQL 8.3から、チェックポイントの書き出しは、開始してから次のチェックポイントの間で分散されます。 checkpoint_completion_targetパラメータをデフォルトの0.5（次のチェックポイントの50%が行われた時に終了することが目的）から通常の最大値0.9（次のチェックポイントの90%の時間までに終了することが目的）まで増やすことにより、書き出しオーバーヘッドの平均値を小さくして、この書き出しを広げることができます。ゼロに設定すると、過去のバージョンの動作と多少似ます。デフォルトが0.9ではない主な理由は、作業をより広く広めるためにはデフォルトよりも大きくcheckpoint_segmentsの値を設定する必要があるためです。チェックポイントのチューニングについての詳細については、Checkpoints and the Background Writerを参照してください。（これはまた、バックグランドライタのパラメータを調整することが、特に8.2以下で、有用である理由も示します。）

autovacuum max_fsm_pages,max_fsm_relations

自動バキューム処理は本当はユーザが行わなければならないデータベース内部の管理上の雑事の面倒をみます。一般的に、多くの時間またはリソースが必要となるために、定常的なバキューム処理を無効にする必要があると考える場合、それは間違っていることを意味しています。ほとんどすべてのバキューム処理関連の問題の答えは、減らすのではなく、より頻繁にバキュームを行うことです。これにより個々のバキューム操作は終了までの時間が短くなります

しかし、例えば大量データの一括ロード処理を行う時など、短期間であれば自動バキュームを無効にすることは受け入れられます。

PostgreSQL 8.4

PostgreSQL 8.4でFSMは作り直されました。このため以前の推奨は適用できなくなっています。新しいFSMが自身で調整するようになりました(詳細)ので、max_fsm_pagesおよびmax_fsm_relationsという設定はなくなりました。 autovacuumはデフォルトで有効であり、可視性マップのため8.4では以前に比べバキュームがかなりでしゃばることがなくなりましたので、変更すべきではありません。

PostgreSQL 8.3 and earlier

8.3ではデフォルトで有効になりました。これは有効のままにしておくべきです。 8.1と8.2では、ユーザ自身が有効にする必要があります。これらの過去のバージョンでは、十分積極的になるように設定を多少いじらなければならないかもしれません。大規模なデータベース、または更新が激しい場合はデフォルトでは十分動作しない可能性があります。

また必要に応じてmax_fsm_pagesとmax_fsm_relationsの値を増やす必要があるかもしれません。空き領域マップは回収可能な不要タプル（行）が存在するかどうかを追跡するために使用されます。不要タプルが空き領域マップに列挙されている場合のみ、効率的な非ブロックバキューム問い合わせを行います。結果として、定期的にバキュームを行う計画を立てない場合、かつ、多くの更新があると予想される場合、これらの値が通常大きいことを確認しなければなりません（そしてこれらの値がデータベースに対するものではなく、データベースクラスタに対するものであることは忘れないでください）。 max_fsm_relationsを十分大きく設定することは簡単なはずです。よく起きる問題は、max_fsm_pagesが十分大きく設定されていない場合です。空き領域マップが一杯になると、バキュームはそれ以上不要ページを追跡することができません。これを1000よりも大きく設定する必要があります。これらの設定の変更にはデータベースの再起動が必要なことを忘れないでください。これらの設定には十分なゆとりをもたせることを勧めます。

データベースに対してVACUUM VERBOSEを実行する場合、使用中のページ数とリレーション数（、8.3では現在の制限）を通知します。以下に例を示します。

INFO:  free space map contains 5293 pages in 214 relations
DETAIL:  A total of 8528 page slots are in use (including overhead).
8528 page slots are required to track all free space.
Current limits are:  204800 page slots, 1000 relations, using 1265 kB.

設定が十分小さいことが分かったら、システムを積極的にバキュームさせる必要があると考えるでしょう。またおそらくインデックスの再作成や完全なバキュームも同様に必要と考えるでしょう。ページスロットの制限に近づいた場合、単に現在の値の倍にすることが通常の対策です。十分大きく（100万単位の範囲）していたとすると増加率はおそらくこれより小さくなります。最大のリレーションの設定では、この設定がクラスタ内のすべてのデータベースを含んでいることに注意してください。

他に注意すべき状況の1つとして、autovacuum_freeze_max_ageにデータベースが近づいていることがあります。データベースがこの点に到達すると、これまでバキューム処理されていないデータベース内のすべてのテーブルのバキュームを始めます。一部のシステムではこれは大きな活動にはならないかもしれませんが、更新が頻繁にないテーブルを多く持つシステム（特に例えばアップグレードなどダンプ/リストアを経験したシステム）では、これはより一般的に発生し得ます。これが重要な点は、十分にfsmの設定を行ったシステムであっても、システムが追加テーブルすべてに対するバキュームを始めると、以前のfsmの設定が不適切になる可能性があることです。

logging

重要かどうかはユーザによって異なりますが、多くの事象をログに記録することができます。ユーザ自身がこのオプションについての文書を調査すべきですが、これから始める方向けにいくつかヒントを以下に示します。

log_destination & log_directory (& log_filename):
log_destination & log_directory (& log_filename):

このオプションに何を設定したかは、これらがデータベースサーバのログをどこに記録するかを決めるヒントを与えることを知ることと同様重要ではありません。最善の実践は、サーバ間でできるだけ共通化するように試みることです。データベースを開始する起動スクリプトにおいて、データベースを開始する時に使用するコマンドラインでpostgresql.conf内の設定を上書きしてログの出力先を変更していること（そして、起動スクリプトを使用せずにpg_ctlを手作業で実行した場合に異なる動作となってしますこと）が、時々あります。

log_min_error_statement: エラーを引き起こしたSQLコマンドが分かるように、おそらく確実に最低エラーに設定すべきです。最近のバージョンではデフォルトにしておくべきです。

log_min_duration_statement: 日々の使用では必要ありませんが、これによりシステムでlogs of "slow queries"を生成することができます。

log_line_prefix: 行の先頭に情報を追加します。一般的は'%t:%r:%u@%d:[%p]: 'が優れていますので推奨します。

ここで%tはタイムスタンプ、%uはデータベースユーザ名、%rは接続元のホスト、%dは接続先のデータベース、%pは接続のPIDを示します。最初はどのPIDが有用か明確でないかもしれませんが、今後の問題解決を試みる時に極めて重要なものになることがあります。ですので最初からログに記録することを勧めます。

log_statement: none（なし）、ddl、mod（DML）、all（すべて）から選択します。運用段階でallを使用すると、性能の劣化をもたらします。例えば「無謀なDBA」により推奨処理手順に従わずに行われた不正な変更を見つける際にDDLが役に立つことがあります。

default_statistics_target

データベースソフトウェアはデータベース内の各テーブルについて、そのテーブルに対する問い合わせの実行方法を決定するために、統計情報を収集します。古めのバージョンのPostgreSQLのデフォルトの10という値ではあまり多くの情報を収集しません。特に大規模（または変動が多い）テーブルに対して優れた実行問い合わせ計画が得られない場合、default_statistics_targetを増やし、データベースに対してANALYZEを再実行（または自動バキュームが代行するまで待機）すべきです。

PostgreSQL 8.4以降

PostgreSQL 8.4でdefault_statistics_targetの初期値が10から100に変わりました。 100より大きな値に増やすことはまだまだ有用になることがあります。増加することでデフォルト設定の統計情報推定を大きく改良します。また8.4では、このパラメータの最大値も1000から10000に変わりました。

work_mem maintainance_work_mem

複雑なソート処理を多く実行し、かつ大量のメモリがあるのであれば、work_memパラメータを増やすことによりPostgreSQLはメモリ内で大規模なソートを行うことができるようになります。驚くことではないと思いますが、ディスクベースで同じことを行う場合と比べて高速です。

このサイズは、各ユーザによって行われるソート1つ1つに適用されます。また複雑な問い合わせでは、作業用メモリソートバッファを複数使用することができます。これを50MBに設定し、30ユーザが問い合わせを実行すると、実メモリとして1.5GB使用することになります。さらに、8テーブルのマージソート処理を含む問い合わせでは、work_memの8倍が必要になります。このパラメータのサイズを正確にするためにmax_connectionsの設定も検討しなければなりません。これはデータウェアハウスシステム向けの設定であり、ここではユーザは非常に大規模な問い合わせを行いますので、すぐに数ギガバイト単位のメモリが使用されます。

maintenance_work_memはバキュームなどの操作で使用されます。ここで極端に大きな値を使っても大して役に立ちません。基本的にバキュームが始まる時にそのメモリを確保する必要がありますので、より有用な目的で使用できなくなります。体験に基づくものですが、256MB程度で十分な大きさです。

PostgreSQL 8.3以降

8.3では、ソートがメモリ内に収まらずにディスクを使用することになったことが分かるようにlog_temp_filesを使用することができます。以前のバージョンでは代わりに各種の$PGDATA/base/<db oid>/pgsql_tmpファイル内で使用された容量を確認することで、ソートサイズを監視することになります。 EXPLAIN ANALYZEの計画内でもディスクへのソートが起きるかどうかを確認することができます。例えばSort Method: external merge Disk: 7526kB"のような行があるとすると、最低8MBのwork_memにより、ディスクに吐き出すことなくRAM内でソート処理が行われますので、問い合わせの実行速度が向上することが分かります。

wal_sync_method wal_buffers

すべてのトランザクションの後、PostgreSQLは強制的にコミットを先行書き込みログに書き出します。これは複数の方法で行うことができ、一部のプラットフォームでは保守的なデフォルトではなく別のオプションを使うことでかなり高速になります。サポートしているプラットフォームであればデフォルトからopen_syncへの変更、そうでなければデフォルトからfsync系の方法の1つに変更することが一般的です。この話題の背景に関する情報が多く記載されていますので、Tuning PostgreSQL WAL Synchronizationを参照してください。一部のプラットフォーム(Linuxなど)のopen_sync書き出しには不具合があることに注意してください。このため、書き込み負荷を高くして十分な試験を（通常通り）行い、この変更によりシステムの安定性が損なわれないことを確認すべきです。 Reliable Writesにはこの話題に関する詳細が記載されています。

2.6.33以降のLinuxカーネルでは、PostgreSQLの古めのバージョンではデフォルトでwal_sync_method=open_datasyncになります。このカーネルリリースの前はデフォルトは常にfdatasyncが選択されました。これあ、小規模の書き出し、小さなwal_buffer値、またはその両方という組み合わせで、大きな性能劣化をもたらすかもしれません。

wal_buffersを数キロバイトの小さなデフォルトより増加させることは書き込みが激しいシステムで役に立ちます。ベンチマークでは通常、多少大規模なシステムでは1MBまで増やすだけで十分であると提案します。またWALセグメント全体（16MB、ここでは有用な上限）を割り当てる最近のサーバでメモリを提供することが合理的です。 wal_buffersの変更はデータベースの再起動が必要です。

PostgreSQL 9.1以降

PostgreSQL 9.1から、wal_buffersはデフォルトでshared_buffersの容量の1/32になり、また上限は16MB（shared_buffersが512MBの時に達する値）になりました。

PostgreSQL 9.1ではまた、新しめのLinuxカーネルなどにおけるデフォルトのwal_sync_methodの選択ロジックを変更しました。これは古めのバージョンのLinuxと同様にfdatasyncを選択するようになります。

constraint_exclusion

PostgreSQL 8.4以降

8.4ではconstraint_exclusionはデフォルトで新しいpartitionという選択になります。これはパーティション化されたテーブルに対してのみ制約による除外を有効にし、ほとんどすべての状況に応じて正しいことを行います。

PostgreSQL 8.3以前

テーブルパーティショニングの利用を計画している場合、制約による除外を有効にしなければなりません。問い合わせ計画作成にオーバーヘッドが加わりますので、こうした状況でなければ無効のままにすることを勧めます。

max_prepared_transactions

この設定は二相コミットの管理に使用されます。二相コミットを使用しない場合（もしこれが何か知らなければ使用しません）、この値をゼロに設定することができます。これにより共有メモリの使用量が多少節約されます。同時接続数が多い（最低数百程度）データベースシステムでは、この設定がpg_locksにおける利用可能なロックスロット数にも影響を与えることに注意してください。このためデフォルトの設定のままにしようと考えるかもしれません。割り当てメモリ量の計算式がin the docsおよびデフォルトのpostgresql.conf内に記載されています。

max_prepared_transactionsの変更にはサーバの再起動が必要です。

synchronous_commit

PostgreSQLはバッテリバックアップ付きの書き込みキャッシュのみを安全に使用することができます。この話題の基本的な入門情報としてWAL reliabilityを参照してください。いや、実際、ここですぐに読んでください。データベースを正しく動作させたければこれを理解することは重要です。

こうした永続性がある書き込みキャッシュが存在しない状況では、1クライアントが1秒当たりに行うトランザクションはおおよそ100までに制限される可能性があります。（おそらくクライアント数が多かったとしても1秒当たり500にしかならないかもしれません。）

PostgreSQL 8.3以降

同期コミットはPostgreSQL 8.3で導入されました。多少のデータ損失が受け入れる代わりに、1秒当たりにデータベースに行うことができる更新数を大きく増大させたい状況では、同期コミットを無効にすることを検討してください。ディスクコントローラにバッテリバックアップされた書き込みキャッシュがない状況では、潜在的に1秒当たりのコミット数が数百から数千まで向上させることができますので、これは特に有用です。

以前のバージョンのPostgreSQLでは、忙しいシステムで書き込み速度を向上させるためにfsync=offと設定するように勧める方を見つけるかもしれません。これは危険です。停電によりデータベースが破損し、再起動できなくなってしまうことがあり得ます。同期コミットは最悪の破損という危険はありません。ただデータ損失という危険は多少あります。

random_page_cost

この設定は、ランダムディスクページをシークするためにディスクにかける時間を、シーケンシャルな読み取りにかかる時間（をコスト1.0とした）乗数として、オプティマイザに通知します。特に、SCSIディスクによるRAIDアレイなど、高速なディスクを使用しているのであれば、random_page_costをより低くすることが適切になることがあります。これにより、問い合わせオプティマイザがより積極的にランダムアクセスによるインデックススキャンを使用するようになります。最近のハードウェアであれば4.0で十分大きいと考える人もいますが、この設定を常に2.0から3.0の間で標準化させることを選ぶ管理者は少なくありません。 random_page_costが高すぎ（2.0以下の設定が通常必要でした）、今より計画の最適化を台無しにしがちな、過去のバージョンのPostgreSQLの振舞いが残っている状況がまれにあります。このコスト推定値は単なる--推定値--です。値を小さく使用とは考えないでください。

しかし、これは計画に関する問題解決を始めるところではありません。 random_page_costがこのリストのかなり下（実際一番最後）にあることに注目してください。悪い計画になったとしても、またこの値を小さくして効果があったとしても、これは検討する最初の項目ではありません。代わりに自動バキュームが適切に動作しているかどうかを確認することから始めてください。そして十分な統計情報を収集しているか、サーバのメモリに関するパラメータを正しく割り当てているかを確認してください。これはすべてこれまで説明してきたことです。これらのより重要な事柄を行っても、悪い計画となり続けるのであれば、random_page_costを小さくしたら有用かどうかを確認してください。