私はpostgresql 9.3を使用していて、インデックスがテーブルよりも大きい方法と理由を理解しようとしています。
出力例:
database_name | database_size | table_name | table_size | indexes_size | total_size
---------------+---------------+--------------------------------------------------------------+------------+--------------+------------
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_sends" | 57 MB | 131 MB | 189 MB
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_started" | 17 MB | 39 MB | 56 MB
foo_12345 | 412 MB | "foobar_dev_12345"."fact_mobile_stopped" | 16 MB | 35 MB | 51 MB
次のクエリを実行して、テーブルとインデックスのサイズを取得しています。
SELECT
table_catalog AS database_name,
pg_size_pretty(pg_database_size(current_database())) As database_size,
table_name,
pg_size_pretty(table_size) AS table_size,
pg_size_pretty(indexes_size) AS indexes_size,
pg_size_pretty(total_size) AS total_size
FROM (
SELECT
table_catalog,
pg_database_size(current_database()) AS database_size,
table_name,
pg_table_size(table_name) AS table_size,
pg_indexes_size(table_name) AS indexes_size,
pg_total_relation_size(table_name) AS total_size
FROM (
SELECT ('"' || table_schema || '"."' || table_name || '"') AS table_name, table_catalog
FROM information_schema.tables
) AS all_tables
ORDER BY total_size DESC
) AS pretty_sizes;
私のクエリは正しいですか?インデックスが大きくなる原因は何ですか?
考えられる理由:
テーブル上の多数の、おそらく重複するインデックス。 \d
でご覧ください
更新パターンによっては、更新のチャーンが多いために膨張して、テーブルよりもインデックスに影響が出る場合があります。個々のインデックスのサイズを調べて、意味があるかどうかを確認します。
要点索引を使用すると、非常に大きくなる可能性があります
pg_table_size
にはTOAST
テーブルが含まれているため、最初にこれがnotであるとは異なり、TOAST
の行外ストレージがカウントされないという問題があります。
インデックスの膨張が気になり、関係するすべてのインデックスの一部をREINDEX
に決定する場合、テーブルが大量の更新を受ける可能性がある場合は、デフォルト以外のFILLFACTOR
を最初に設定することを検討してください(または挿入+削除)。そうしないと、インデックスに新しい値を挿入するためのスペースがないために書き込みパフォーマンスが低下し、多くのページ分割が強制されて効率が低下します。