La façon la plus simple de construire un index GiST est justement d'insérer toutes les entrées, une par une. Ceci tend à être lent pour les index volumineux parce que, si les entrées d'index sont réparties partout dans l'index et que l'index est suffisamment gros pour ne pas tenir en cache, un grand nombre d'accès disque aléatoires seront nécessaires. PostgreSQL accepte deux méthodes alternatives pour une construction initiale d'un indexGiST : le mode sorted (trié) et le mode buffered (tampon).

La méthode par tri est seulement disponible si chacune des classes d'opérateur utilisée par l'index fournit une fonction sortsupport, comme décrit dans Section 65.3. Si c'est le cas, cette méthode est généralement la meilleure, donc elle est utilisée par défaut.

La méthode par cache fonctionne en n'insérant pas les lignes directement et immédiatement dans l'index. Il peut réduire fortement la quantité d'accès disques aléatoires nécessaire pour les ensembles de données non triés. Pour les ensembles de données bien triés, le bénéfice est plus petit, voire inexistant car seul un petit nombre de blocs reçoit de nouvelles lignes à un instant t, et ces blocs tiennent en cache même si l'index complet ne le peut pas.

La méthode par cache a besoin d'appeler la fonction penalty plus souvent que ne le fait la méthode simple, ce qui consomme des ressources CPU supplémentaires. De plus, le cache a besoin d'un espace disque supplémentaire allant jusqu'à la taille de l'index résultant. L'utilisation de tampons peut aussi influencer la qualité de l'index résultant, de façon positive et négative. Cette influence dépend de plusieurs facteurs, comme la distribution des données en entrée et de l'implémentation de la classe d'opérateur.

Si le tri n'est pas possible, alors par défaut la construction d'un index GiST bascule sur la méthode par cache quand la taille de l'index atteint effective_cache_size. L'utilisation du cache peut être forcée ou empêchée manuellement avec le paramètre buffering de la commande CREATE INDEX. Le comportement par défaut est bon dans la plupart des cas mais désactiver le cache pourrait accélérer un peu la construction si les données en entrée sont triées.