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 to only 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 R-trees. That means that you can use
PostgreSQL to build a B+-tree or R-tree over any
data type you want. But B+-trees only support range predicates
(<, =, >),
and R-trees only support n-D range queries (contains, contained, equals).
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.
