皆さん、ありがとうございます!重複キーを修正し、不要なインデックスを削除してから、以下のコマンドを正常に実行しました。
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
CPU使用率は正常に戻りました。ふぅ。
質問:最適化されていないデータベースや壊れたインデックスが、postmaster のCPU使用率をこれほど高くなる原因となるのはなぜでしょうか?単なる好奇心です。
皆さん、ありがとうございます!重複キーを修正し、不要なインデックスを削除してから、以下のコマンドを正常に実行しました。
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
CPU使用率は正常に戻りました。ふぅ。
質問:最適化されていないデータベースや壊れたインデックスが、postmaster のCPU使用率をこれほど高くなる原因となるのはなぜでしょうか?単なる好奇心です。
壊れたインデックスは誤った手がかりだと思います。確かに問題ではあり、修正すべきですが。
真の大きな問題は、10 から 12 への移行により、データベースの統計情報が極めて不正確になることです。これがパフォーマンスの低下を招きます。
パフォーマンスが悪化するのは、クエリ最適化器がデータに関する統計情報が完全にズレているため、非常に不適切な実行計画を選択してしまうからです。
統計情報の再構築を vacuum 経由で行う機能を、自動化された移行プロセスに統合する予定です。
@sam さん、ご説明ありがとうございます。なるほど、納得しました。リビルドを自動移動に統合するのは良いアイデアですね。再度、ご協力いただきありがとうございます!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.