web-dev-qa-db-ja.com

PostgreSQLインデックス使用分析

Postgresを分析し、作成する必要がある欠落インデックスと削除する必要のある未使用インデックスを決定するツールまたは方法はありますか？ SQLServerの「プロファイラー」ツールを使用してこれを実行した経験は少しありますが、Postgresに含まれている同様のツールについては知りません。

sqldatabase-designpostgresql
77
Cerin

私はこれが欠けているインデックスを見つけるのが好きです：

SELECT
  relname                                               AS TableName,
  to_char(seq_scan, '999,999,999,999')                  AS TotalSeqScan,
  to_char(idx_scan, '999,999,999,999')                  AS TotalIndexScan,
  to_char(n_live_tup, '999,999,999,999')                AS TableRows,
  pg_size_pretty(pg_relation_size(relname :: regclass)) AS TableSize
FROM pg_stat_all_tables
WHERE schemaname = 'public'
      AND 50 * seq_scan > idx_scan -- more then 2%
      AND n_live_tup > 10000
      AND pg_relation_size(relname :: regclass) > 5000000
ORDER BY relname ASC;

これは、インデックススキャンよりもシーケンススキャンの方が多いかどうかをチェックします。テーブルが小さい場合、Postgresはそれらのシーケンススキャンを好むため、無視されます。

上記のクエリは、欠落しているインデックスを明らかにします。

次のステップは、結合インデックスの欠落を検出することです。これは簡単ではありませんが、実行可能です。たぶん、遅いクエリを分析しています... pg_stat_statements が役立つと聞きました...

149
guettli

統計を確認してください。 pg_stat_user_tablesおよびpg_stat_user_indexesは、最初のものです。

「 The Statistics Collector 」を参照してください。

19
Frank Heikens

欠落インデックスの判別のアプローチについて..。しかし、擬似インデックスや機械可読EXPLAINなど、将来のリリースでこれを簡単にする計画がいくつかあります。

現在、EXPLAIN ANALYZEパフォーマンスの低いクエリを実行し、最適なルートを手動で決定します。 pgFouine などの一部のログアナライザーは、クエリの決定に役立ちます。

未使用のインデックスに関しては、次のようなものを使用してそれらを識別できます。

select * from pg_stat_all_indexes where schemaname <> 'pg_catalog';

これは、読み取り、スキャン、フェッチされたタプルの識別に役立ちます。

8
rfusca

PostgreSQLを分析するための別の新しい興味深いツールは、 PgHero です。データベースの調整に重点を置き、多数の分析と提案を行います。

screenshot

6
n1000

PostgreSQL wiki には、未使用のインデックスを見つけるのに役立つスクリプトへのリンクが複数あります。基本的な手法は、_pg_stat_user_indexes_を見て、そのインデックスがクエリへの応答に使用された回数の__idx_scan_がゼロ、または少なくとも非常に低いものを探すことです。アプリケーションが変更され、以前使用されていたインデックスがおそらく現在ではない場合、pg_stat_reset()を実行してすべての統計を0に戻し、新しいデータを収集する必要がある場合があります。すべての現在の値を保存し、代わりにデルタを計算してそれを把握することができます。

不足しているインデックスを示唆する良いツールはまだありません。 1つのアプローチは、pgFouineやpqaなどのクエリログ分析ツールを使用して、実行中のクエリをログに記録し、実行に時間がかかっているクエリを分析することです。詳細については、「 Logging Difficult Queries 」を参照してください。

もう1つの方法は、_pg_stat_user_tables_を見て、それらに対して多数の順次スキャンがあるテーブルを探すことです。ここで、_seq_tup_fetch_は大きいです。インデックスが使用されると、代わりに_idx_fetch_tup_カウントが増加します。これは、テーブルに対するインデックスが十分に作成されていないため、クエリに対する回答が得られない場合に役立ちます。

次に、どの列にインデックスを付ける必要があるかを実際に把握していますか？これは通常、クエリログ分析に戻ります。

3
Greg Smith

以下のクエリを使用して、インデックスの使用状況とインデックスサイズを見つけることができます：

参照はこのブログから取られています。

SELECT
    pt.tablename AS TableName
    ,t.indexname AS IndexName
    ,to_char(pc.reltuples, '999,999,999,999') AS TotalRows
    ,pg_size_pretty(pg_relation_size(quote_ident(pt.tablename)::text)) AS TableSize
    ,pg_size_pretty(pg_relation_size(quote_ident(t.indexrelname)::text)) AS IndexSize
    ,to_char(t.idx_scan, '999,999,999,999') AS TotalNumberOfScan
    ,to_char(t.idx_tup_read, '999,999,999,999') AS TotalTupleRead
    ,to_char(t.idx_tup_fetch, '999,999,999,999') AS TotalTupleFetched
FROM pg_tables AS pt
LEFT OUTER JOIN pg_class AS pc 
    ON pt.tablename=pc.relname
LEFT OUTER JOIN
( 
    SELECT 
        pc.relname AS TableName
        ,pc2.relname AS IndexName
        ,psai.idx_scan
        ,psai.idx_tup_read
        ,psai.idx_tup_fetch
        ,psai.indexrelname 
    FROM pg_index AS pi
    JOIN pg_class AS pc 
        ON pc.oid = pi.indrelid
    JOIN pg_class AS pc2 
        ON pc2.oid = pi.indexrelid
    JOIN pg_stat_all_indexes AS psai 
        ON pi.indexrelid = psai.indexrelid 
)AS T
    ON pt.tablename = T.TableName
WHERE pt.schemaname='public'
ORDER BY 1;
3
Anvesh

PoWA はPostgreSQL 9.4+にとって興味深いツールのようです。統計を収集して視覚化し、インデックスを提案します。 pg_stat_statements 拡張。

PoWAは、パフォーマンス統計を収集し、PostgreSQLサーバーの監視と調整に役立つリアルタイムのチャートとグラフを提供するPostgreSQLワークロードアナライザーです。 Oracle AWRまたはSQL Server MDWに似ています。

1
n1000
CREATE EXTENSION pgstattuple; 
CREATE TABLE test(t INT); 
INSERT INTO test VALUES(generate_series(1, 100000)); 
SELECT * FROM pgstatindex('test_idx'); 

version            | 2 
tree_level         | 2 
index_size         | 105332736 
root_block_no      | 412 
internal_pages     | 40 
leaf_pages         | 12804 
empty_pages        | 0 
deleted_pages      | 13 
avg_leaf_density   | 9.84 
leaf_fragmentation | 21.42
0
madjardi