Suppose we have a table similar to this: 次のようなテーブルを考えてみましょう。

CREATE TABLE test1 (
    id integer,
    content varchar
);

and the application issues many queries of the form: アプリケーションはこの形式の多くの問い合わせを発行します。

SELECT content FROM test1 WHERE id = constant;

With no advance preparation, the system would have to scan the entire <structname>test1</structname> table, row by row, to find all matching entries. If there are many rows in <structname>test1</structname> and only a few rows (perhaps zero or one) that would be returned by such a query, this is clearly an inefficient method. But if the system has been instructed to maintain an index on the <structfield>id</structfield> column, it can use a more efficient method for locating matching rows. For instance, it might only have to walk a few levels deep into a search tree. 事前に準備を行っていなければ、システムで一致する項目を全て検出するためには、test1テーブル全体を1行ごとにスキャンする必要があります。 test1に数多くの行があり、その問い合わせで返されるのが数行（おそらく0行か1行）しかない場合、これは明らかに効率が悪い方法と言えます。 システムがインデックスをid列上で維持するように指示されていれば、一致する行を検出するのにより効率の良い方法を使うことができます。 例えば、検索ツリーを数層分検索するだけで済む可能性もあります。

A similar approach is used in most non-fiction books: terms and concepts that are frequently looked up by readers are collected in an alphabetic index at the end of the book. The interested reader can scan the index relatively quickly and flip to the appropriate page(s), rather than having to read the entire book to find the material of interest. Just as it is the task of the author to anticipate the items that readers are likely to look up, it is the task of the database programmer to foresee which indexes will be useful. ほとんどのノンフィクションの本で、同じような手法が使われています。 読者が頻繁に調べる用語および概念は、その本の最後にアルファベット順に索引としてまとめられています。 その本に興味を持った読者は、索引（インデックス）を調べ、比較的速く簡単に該当するページを開くことができるため、見たい場所を探すために本全部を読む必要はありません。 読者がよく調べそうな項目を予想するのが作者の仕事であるように、どのインデックスが実用的であるかを予測するのはデータベースプログラマの仕事です。

The following command can be used to create an index on the <structfield>id</structfield> column, as discussed: 上述のようにid列にインデックスを作成する場合は、以下のようなコマンドが使用できます。

CREATE INDEX test1_id_index ON test1 (id);

The name <structname>test1_id_index</structname> can be chosen freely, but you should pick something that enables you to remember later what the index was for. test1_id_indexというインデックス名には、何を選んでも構いませんが、そのインデックスを何のために作成したかを後で思い出せるような名前を選ぶべきです。

To remove an index, use the <command>DROP INDEX</command> command. Indexes can be added to and removed from tables at any time. インデックスを削除するには、DROP INDEXコマンドを使用します。 テーブルのインデックスは、いつでも追加および削除できます。

Once an index is created, no further intervention is required: the system will update the index when the table is modified, and it will use the index in queries when it thinks doing so would be more efficient than a sequential table scan. But you might have to run the <command>ANALYZE</command> command regularly to update statistics to allow the query planner to make educated decisions. See <xref linkend="performance-tips"/> for information about how to find out whether an index is used and when and why the planner might choose <emphasis>not</emphasis> to use an index. いったんインデックスを作成すれば、それ以上の処理は必要はありません。 システムは、テーブルが変更される時インデックスを更新し、シーケンシャルスキャンよりもインデックススキャンを行うことがより効率的と判断した場合、問い合わせでインデックスを使用します。 しかし、問い合わせプランナで情報に基づいた判断をするためには、定期的にANALYZEコマンドを実行し、統計情報を更新する必要があるかもしれません。 インデックスが使われているかどうか、およびプランナがインデックスを使わないと判断した状況および理由を調べる方法については、第14章を参照してください。

Indexes can also benefit <command>UPDATE</command> and <command>DELETE</command> commands with search conditions. Indexes can moreover be used in join searches. Thus, an index defined on a column that is part of a join condition can also significantly speed up queries with joins. インデックスは、UPDATEやDELETEコマンドの検索条件でも使用できます。 さらに、インデックスは結合問い合わせでも使用されます。 したがって、結合条件で記述されている列にインデックスを定義すれば、結合を伴った問い合わせにかかる時間もかなり短縮できます。

Creating an index on a large table can take a long time. By default, <productname>PostgreSQL</productname> allows reads (<command>SELECT</command> statements) to occur on the table in parallel with index creation, but writes (<command>INSERT</command>, <command>UPDATE</command>, <command>DELETE</command>) are blocked until the index build is finished. In production environments this is often unacceptable. It is possible to allow writes to occur in parallel with index creation, but there are several caveats to be aware of &mdash; for more information see <xref linkend="sql-createindex-concurrently"/>. 大規模テーブルに対するインデックス作成が長時間にわたる可能性があります。 デフォルトでPostgreSQLはインデックス作成と並行してテーブルを読み取る（SELECT文）ことができますが、書き込み（INSERT、UPDATE、DELETE）はインデックス作成が終わるまでブロックされます。 これは多くの運用環境では受け入れられません。 インデックス作成中でも並行して書き込みできるようにすることができますが、いくつか注意しなければならないことがあります。 インデックスの同時作成の情報を参照してください。

After an index is created, the system has to keep it synchronized with the table. This adds overhead to data manipulation operations. Indexes can also prevent the creation of <link linkend="storage-hot">heap-only tuples</link>. Therefore indexes that are seldom or never used in queries should be removed. インデックスが作成された後、システムでは、テーブルとインデックスとの間で常に同期を取っておく必要があります。 これにより、データ操作の処理にオーバーヘッドが加わります。 インデックスはまた、ヒープ専用タプルの作成を防いでしまいます。 したがって、めったに使用されないインデックスや、まったく使用されなくなったインデックスは、削除しておいた方が良いでしょう。