インデックスの再構築 - AWS 規範ガイダンス
新しいインデックスの作成インデックスの再構築例

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

インデックスの再構築

PostgreSQL REINDEX コマンドは、インデックスのテーブルに保存されているデータを使用してインデックスを再構築し、インデックスの古いコピーを置き換えます。以下のシナリオREINDEXでは、 を使用することをお勧めします。

  • インデックスが破損し、有効なデータが含まれなくなった場合。これは、ソフトウェアまたはハードウェアの障害の結果として発生する可能性があります。

  • 以前にインデックスを使用したクエリが使用を停止した場合。

  • インデックスが多数の空のページまたはほぼ空のページで肥大化した場合。膨張率 (bloat_pct) が 20 より大きいREINDEXときに を実行する必要があります。

次のクエリは、 を見つけるのに役立ちますbloat_pct。

SELECT current_database(), nspname AS schemaname, tblname, idxname, bs*(relpages)::bigint AS real_size,
  bs*(relpages-est_pages)::bigint AS extra_size,
  100 * (relpages-est_pages)::float / relpages AS extra_pct,
  fillfactor,
  CASE WHEN relpages > est_pages_ff
    THEN bs*(relpages-est_pages_ff)
    ELSE 0
  END AS bloat_size,
  100 * (relpages-est_pages_ff)::float / relpages AS bloat_pct,
  is_na
  -- , 100-(pst).avg_leaf_density AS pst_avg_bloat, est_pages, index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples, relpages -- (DEBUG INFO)
FROM (
  SELECT coalesce(1 +
         ceil(reltuples/floor((bs-pageopqdata-pagehdr)/(4+nulldatahdrwidth)::float)), 0 -- ItemIdData size + computed avg size of a tuple (nulldatahdrwidth)
      ) AS est_pages,
      coalesce(1 +
         ceil(reltuples/floor((bs-pageopqdata-pagehdr)*fillfactor/(100*(4+nulldatahdrwidth)::float))), 0
      ) AS est_pages_ff,
      bs, nspname, tblname, idxname, relpages, fillfactor, is_na
      -- , pgstatindex(idxoid) AS pst, index_tuple_hdr_bm, maxalign, pagehdr, nulldatawidth, nulldatahdrwidth, reltuples -- (DEBUG INFO)
  FROM (
      SELECT maxalign, bs, nspname, tblname, idxname, reltuples, relpages, idxoid, fillfactor,
            ( index_tuple_hdr_bm +
                maxalign - CASE -- Add padding to the index tuple header to align on MAXALIGN
                  WHEN index_tuple_hdr_bm%maxalign = 0 THEN maxalign
                  ELSE index_tuple_hdr_bm%maxalign
                END
              + nulldatawidth + maxalign - CASE -- Add padding to the data to align on MAXALIGN
                  WHEN nulldatawidth = 0 THEN 0
                  WHEN nulldatawidth::integer%maxalign = 0 THEN maxalign
                  ELSE nulldatawidth::integer%maxalign
                END
            )::numeric AS nulldatahdrwidth, pagehdr, pageopqdata, is_na
            -- , index_tuple_hdr_bm, nulldatawidth -- (DEBUG INFO)
      FROM (
          SELECT n.nspname, i.tblname, i.idxname, i.reltuples, i.relpages,
              i.idxoid, i.fillfactor, current_setting('block_size')::numeric AS bs,
              CASE -- MAXALIGN: 4 on 32bits, 8 on 64bits (and mingw32 ?)
                WHEN version() ~ 'mingw32' OR version() ~ '64-bit|x86_64|ppc64|ia64|amd64' THEN 8
                ELSE 4
              END AS maxalign,
              /* per page header, fixed size: 20 for 7.X, 24 for others */
              24 AS pagehdr,
              /* per page btree opaque data */
              16 AS pageopqdata,
              /* per tuple header: add IndexAttributeBitMapData if some cols are null-able */
              CASE WHEN max(coalesce(s.null_frac,0)) = 0
                  THEN 8 -- IndexTupleData size
                  ELSE 8 + (( 32 + 8 - 1 ) / 8) -- IndexTupleData size + IndexAttributeBitMapData size ( max num filed per index + 8 - 1 /8)
              END AS index_tuple_hdr_bm,
              /* data len: we remove null values save space using it fractionnal part from stats */
              sum( (1-coalesce(s.null_frac, 0)) * coalesce(s.avg_width, 1024)) AS nulldatawidth,
              max( CASE WHEN i.atttypid = 'pg_catalog.name'::regtype THEN 1 ELSE 0 END ) > 0 AS is_na
          FROM (
              SELECT ct.relname AS tblname, ct.relnamespace, ic.idxname, ic.attpos, ic.indkey, ic.indkey[ic.attpos], ic.reltuples, ic.relpages, ic.tbloid, ic.idxoid, ic.fillfactor,
                  coalesce(a1.attnum, a2.attnum) AS attnum, coalesce(a1.attname, a2.attname) AS attname, coalesce(a1.atttypid, a2.atttypid) AS atttypid,
                  CASE WHEN a1.attnum IS NULL
                  THEN ic.idxname
                  ELSE ct.relname
                  END AS attrelname
              FROM (
                  SELECT idxname, reltuples, relpages, tbloid, idxoid, fillfactor, indkey,
                      pg_catalog.generate_series(1,indnatts) AS attpos
                  FROM (
                      SELECT ci.relname AS idxname, ci.reltuples, ci.relpages, i.indrelid AS tbloid,
                          i.indexrelid AS idxoid,
                          coalesce(substring(
                              array_to_string(ci.reloptions, ' ')
                              from 'fillfactor=([0-9]+)')::smallint, 90) AS fillfactor,
                          i.indnatts,
                          pg_catalog.string_to_array(pg_catalog.textin(
                              pg_catalog.int2vectorout(i.indkey)),' ')::int[] AS indkey
                      FROM pg_catalog.pg_index i
                      JOIN pg_catalog.pg_class ci ON ci.oid = i.indexrelid
                      WHERE ci.relam=(SELECT oid FROM pg_am WHERE amname = 'btree')
                      AND ci.relpages > 0
                  ) AS idx_data
              ) AS ic
              JOIN pg_catalog.pg_class ct ON ct.oid = ic.tbloid
              LEFT JOIN pg_catalog.pg_attribute a1 ON
                  ic.indkey[ic.attpos] <> 0
                  AND a1.attrelid = ic.tbloid
                  AND a1.attnum = ic.indkey[ic.attpos]
              LEFT JOIN pg_catalog.pg_attribute a2 ON
                  ic.indkey[ic.attpos] = 0
                  AND a2.attrelid = ic.idxoid
                  AND a2.attnum = ic.attpos
            ) i
            JOIN pg_catalog.pg_namespace n ON n.oid = i.relnamespace
            JOIN pg_catalog.pg_stats s ON s.schemaname = n.nspname
                                      AND s.tablename = i.attrelname
                                      AND s.attname = i.attname
            GROUP BY 1,2,3,4,5,6,7,8,9,10,11
      ) AS rows_data_stats
  ) AS rows_hdr_pdg_stats
) AS relation_stats
ORDER BY nspname, tblname, idxname;

完全に空のインデックスページは再利用のために再利用されます。ただし、ページのインデックスキーが削除されてもスペースが割り当てられたままの場合は、定期的にインデックスを再作成することをお勧めします。

インデックスを再作成すると、クエリのパフォーマンスが向上します。次の表に示すように、3 つの方法でインデックスを再作成できます。

方法

説明

制約事項

CREATE INDEX CONCURRENTLYオプションDROP INDEX付きの および

新しいインデックスを構築し、古いインデックスを削除します。オプティマイザは、古いインデックスの代わりに新しく作成されたインデックスを使用してプランを生成します。ピーク時間が低いときは、古いインデックスを削除できます。

インデックスの作成には、 CONCURRENTLYオプションを使用する場合に時間がかかります。これは、受信するすべての変更を追跡する必要があるためです。変更がフリーズされると、プロセスは完了としてマークされます。

REINDEX CONCURRENTLYオプションで

再構築プロセス中に書き込みオペレーションをロックします。PostgreSQL バージョン 12 以降のバージョンでは CONCURRENTLYオプションが用意されているため、これらのロックを回避できます。

を使用するには、インデックスの再構築に時間がCONCURRENTLYかかります。

pg_repack 拡張機能

テーブルから肥大化をクリーンアップし、インデックスを再構築します。

この拡張機能は、EC2 インスタンスまたはデータベースに接続されているローカルコンピュータから実行する必要があります。

新しいインデックスの作成

コマンドDROP INDEXと CREATE INDEX コマンドを併用すると、インデックスが再構築されます。

DROP INDEX <index_name>
CREATE INDEX <index_name> ON TABLE <table_name> (<column1>[,<column2>])

このアプローチの欠点は、テーブルに対する排他的ロックであり、このアクティビティ中のパフォーマンスに影響します。DROP INDEX コマンドは排他的ロックを取得し、テーブルに対する読み取りオペレーションと書き込みオペレーションの両方をブロックします。CREATE INDEX コマンドは、テーブルに対する書き込みオペレーションをブロックします。これにより読み取りオペレーションが可能になりますが、インデックスの作成時にコストがかかります。

インデックスの再構築

REINDEX コマンドは、一貫したデータベースパフォーマンスを維持するのに役立ちます。テーブルに対して多数の DML オペレーションを実行すると、テーブルとインデックスの両方が肥大化します。インデックスは、クエリのパフォーマンスを向上させるためにテーブルの検索を高速化するために使用されます。インデックスの肥大化は、ルックアップとクエリのパフォーマンスに影響します。したがって、クエリのパフォーマンスの一貫性を維持するために、DML オペレーションの量が多いテーブルに対してインデックス再作成を実行することをお勧めします。

REINDEX コマンドは、基になるテーブルの書き込みオペレーションをロックすることでインデックスを最初から再構築しますが、テーブルの読み取りオペレーションを許可します。ただし、インデックスの読み取りオペレーションはブロックされます。対応するインデックスを使用するクエリはブロックされますが、他のクエリはブロックされません。

PostgreSQL バージョン 12 では、新しいオプションのパラメータ が導入されました。これは、インデックスをゼロから再構築しますがCONCURRENTLY、テーブルまたはインデックスを使用するクエリに対する書き込みまたは読み取りオペレーションをロックしません。ただし、このオプションを使用すると、プロセスが完了するまでに時間がかかります。

例

インデックスの作成と削除

CONCURRENTLY オプションを使用して新しいインデックスを作成します。

create index CONCURRENTLY on table(columns) ;

CONCURRENTLY オプションを使用して古いインデックスを削除します。

drop index CONCURRENTLY <index name> ;

インデックスの再構築

単一のインデックスを再構築するには：

reindex index <index name> ;

テーブル内のすべてのインデックスを再構築するには：

reindex table <table name> ;

スキーマ内のすべてのインデックスを再構築するには：

reindex schema <schema name> ;

インデックスを同時に再構築する

単一のインデックスを再構築するには：

reindex index CONCURRENTLY <indexname> ;

テーブル内のすべてのインデックスを再構築するには：

reindex table CONCURRENTLY <tablename> ;

スキーマ内のすべてのインデックスを再構築するには：

reindex schema CONCURRENTLY <schemaname> ;

インデックスのみの再構築または再配置

単一のインデックスを再構築するには：

pg_repack -h <hostname> -d <dbname> -i <indexname> -k

すべてのインデックスを再構築するには：

pg_repack -h <hostname> -d <dbname> -x <indexname> -t <tablename> -k