GiSTインデックスを構築する一番簡単な方法は、全項目を単に1つ1つ挿入することです。 インデックスタプルがインデックス全体に分散し、インデックスがキャッシュに収まらない程大規模である場合、大量のランダムI/Oを必要としますので、これは大規模なインデックスに対して低速になりがちです。 PostgreSQLはGiSTインデックスの初期構築のために他に2つの方法をサポートします。ソート処理モードとバッファ処理モードです。

ソート処理法は、インデックスで使われる演算子クラスのそれぞれが、65.3に記載されているようにsortsupportを提供している場合にのみ利用可能です。 もしそうであれば、この方法が普通は最善ですので、デフォルトで使われます。

バッファ処理法はタプルを直ちに直接インデックスに挿入しないことで動作します。 これは、順序付けられていないデータ群に対して必要とされるランダムI/Oの量を劇的に減らすかもしれません。 十分に順序付けられたデータ群では、一度にわずかなページ数のみが新しいタプルを受け取り、そのためインデックス全体がキャッシュに収まらなくてもこれらのページがキャッシュ内に収まりますので、利点はより小さく、または利点がなくなります。

バッファ処理法は、penalty関数を単純な方法よりもより多く呼び出すことが必要で、余計にCPUリソースを消費します。 またバッファは、最大作成されるインデックスと同じサイズまで、一時的にディスク容量を必要とします。 バッファ処理は作成されるインデックスの品質にも、良くも悪くも、影響を与えます。 この影響は、入力データの分布や演算子クラスの実装等、様々な要因に依存します。

ソートが可能でない場合、デフォルトでは、インデックスのサイズがeffective_cache_sizeに達した時にGiSTインデックス構築はバッファ処理法に切り替わります。 バッファ処理はCREATE INDEXコマンドのbufferingパラメータによって、手動で強制あるいは無効にできます。 デフォルトの動作は大抵の場合良好です。 しかし、入力データが順序付けされている場合、バッファ処理を無効にすることで構築が多少高速になります。