56.4. Implémentation

Construire de gros index GiST en insérant simplement toutes les lignes a tendance à être lent car si les lignes de l'index sont dispersées dans tout l'index et que l'index est suffisamment gros pour ne pas tenir dans le cache, les insertions ont besoin de réaliser un grand nombre d'opérations d'entrées/sorties aléatoires. À partir de la version 9.2, PostgreSQL supporte une méthode plus efficace pour construire des index GiST en se basant sur des tampons qui peuvent dramatiquement réduire le nombre d'entrées/sorties aléatoires nécessaires pour les ensembles de données non triées. Pour les ensembles de données déjà bien triées, le gain est plus petit, voire inexistant car seul un petit nombre de pages reçoit des nouvelles lignes à un même instant et ces pages tiennent généralement en cache même si l'index complet ne tient pas.

Néanmoins, la construction d'index par tampon a besoin d'appeler la fonction penalty plus fréquemment, ce qui consomme un peu plus de ressources CPU. De plus, les tampons utilisés lors de cette construction ont besoin d'un espace disque temporaire, 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.

Par défaut, la construction d'un index GiST bascule sur la méthode avec tampons lorsque la taille de l'index atteint effective_cache_size. Cette bascule peut être activée ou désactivé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 l'utilisation des tampons pourrait apporter une amélioration des performances lors de la construction sur les données en entrée sont déjà triées.