Traditionally, implementing a new index access method meant a
lot of difficult work. It was necessary to understand the inner
workings of the database, such as the lock manager and
Write-Ahead Log. The GiST
interface has a high level of abstraction, requiring the access
method implementer only to implement the semantics of the data
type being accessed. The GiST
layer itself takes care of concurrency, logging and searching the
tree structure.

This extensibility should not be confused with the
extensibility of the other standard search trees in terms of the
data they can handle. For example, PostgreSQL supports extensible B-trees and
hash indexes. That means that you can use PostgreSQL to build a B-tree or hash over
any data type you want. But B-trees only support range predicates
(<, =,
>), and hash indexes only support
equality queries.

So if you index, say, an image collection with a PostgreSQL B-tree, you can only issue
queries such as "is imagex equal to
imagey", "is imagex less than
imagey" and "is imagex greater than
imagey". Depending on how you define "equals", "less than"
and "greater than" in this context,
this could be useful. However, by using a GiST based index, you could create ways to
ask domain-specific questions, perhaps "find
all images of horses" or "find all
over-exposed images".

All it takes to get a GiST
access method up and running is to implement seven user-defined
methods, which define the behavior of keys in the tree. Of course
these methods have to be pretty fancy to support fancy queries,
but for all the standard queries (B-trees, R-trees, etc.) they're
relatively straightforward. In short, GiST combines extensibility along with
generality, code reuse, and a clean interface.