The simplest way to build a GiST index is just to insert all the entries, one by one. This tends to be slow for large indexes, because if the index tuples are scattered across the index and the index is large enough to not fit in cache, a lot of random I/O will be needed. <productname>PostgreSQL</productname> supports two alternative methods for initial build of a GiST index: <firstterm>sorted</firstterm> and <firstterm>buffered</firstterm> modes. GiSTインデックスを構築する一番簡単な方法は、全項目を単に1つ1つ挿入することです。 インデックスタプルがインデックス全体に分散し、インデックスがキャッシュに収まらない程大規模である場合、大量のランダムI/Oを必要としますので、これは大規模なインデックスに対して低速になりがちです。 PostgreSQLはGiSTインデックスの初期構築のために他に2つの方法をサポートします。ソート処理モードとバッファ処理モードです。

The sorted method is only available if each of the opclasses used by the index provides a <function>sortsupport</function> function, as described in <xref linkend="gist-extensibility"/>. If they do, this method is usually the best, so it is used by default. ソート処理法は、インデックスで使われる演算子クラスのそれぞれが、68.3に記載されているようにsortsupportを提供している場合にのみ利用可能です。 もしそうであれば、この方法が普通は最善ですので、デフォルトで使われます。

The buffered method works by not inserting tuples directly into the index right away. It can dramatically reduce the amount of random I/O needed for non-ordered data sets. For well-ordered data sets the benefit is smaller or non-existent, because only a small number of pages receive new tuples at a time, and those pages fit in cache even if the index as a whole does not. バッファ処理法はタプルを直ちに直接インデックスに挿入しないことで動作します。 これは、順序付けられていないデータ群に対して必要とされるランダムI/Oの量を劇的に減らすかもしれません。 十分に順序付けられたデータ群では、一度にわずかなページ数のみが新しいタプルを受け取り、そのためインデックス全体がキャッシュに収まらなくてもこれらのページがキャッシュ内に収まりますので、利点はより小さく、または利点がなくなります。

The buffered method needs to call the <function>penalty</function> function more often than the simple method does, which consumes some extra CPU resources. Also, the buffers need temporary disk space, up to the size of the resulting index. Buffering can also influence the quality of the resulting index, in both positive and negative directions. That influence depends on various factors, like the distribution of the input data and the operator class implementation. バッファ処理法は、penalty関数を単純な方法よりもより多く呼び出すことが必要で、余計にCPUリソースを消費します。 またバッファは、最大作成されるインデックスと同じサイズまで、一時的にディスク容量を必要とします。 バッファ処理は作成されるインデックスの品質にも、良くも悪くも、影響を与えます。 この影響は、入力データの分布や演算子クラスの実装等、様々な要因に依存します。

If sorting is not possible, then by default a GiST index build switches to the buffering method when the index size reaches <xref linkend="guc-effective-cache-size"/>. Buffering can be manually forced or prevented by the <literal>buffering</literal> parameter to the CREATE INDEX command. The default behavior is good for most cases, but turning buffering off might speed up the build somewhat if the input data is ordered. ソートが可能でない場合、デフォルトでは、インデックスのサイズがeffective_cache_sizeに達した時にGiSTインデックス構築はバッファ処理法に切り替わります。 バッファ処理はCREATE INDEXコマンドのbufferingパラメータによって、手動で強制あるいは無効にできます。 デフォルトの動作は大抵の場合良好です。 しかし、入力データが順序付けされている場合、バッファ処理を無効にすることで構築が多少高速になります。