1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>49.2.Extensibility</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="gist.html" title="Chapter49.GiST Indexes">
<link rel="prev" href="gist.html" title="Chapter49.GiST Indexes">
<link rel="next" href="gist-implementation.html" title="49.3.Implementation">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="gist-extensibility"></a>49.2.Extensibility</h2></div></div></div>
<p> 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
<acronym class="acronym">GiST</acronym> interface has a high level of abstraction,
requiring the access method implementer to only implement the semantics of
the data type being accessed. The <acronym class="acronym">GiST</acronym> layer itself
takes care of concurrency, logging and searching the tree structure.
</p>
<p> 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, <span class="productname">PostgreSQL</span> supports extensible B+-trees
and R-trees. That means that you can use
<span class="productname">PostgreSQL</span> to build a B+-tree or R-tree over any
data type you want. But B+-trees only support range predicates
(<code class="literal"><</code>, <code class="literal">=</code>, <code class="literal">></code>),
and R-trees only support n-D range queries (contains, contained, equals).
</p>
<p> So if you index, say, an image collection with a
<span class="productname">PostgreSQL</span> B+-tree, you can only issue queries
such as “<span class="quote">is imagex equal to imagey</span>”, “<span class="quote">is imagex less
than imagey</span>” and “<span class="quote">is imagex greater than imagey</span>”?
Depending on how you define “<span class="quote">equals</span>”, “<span class="quote">less than</span>”
and “<span class="quote">greater than</span>” in this context, this could be useful.
However, by using a <acronym class="acronym">GiST</acronym> based index, you could create
ways to ask domain-specific questions, perhaps “<span class="quote">find all images of
horses</span>” or “<span class="quote">find all over-exposed images</span>”.
</p>
<p> All it takes to get a <acronym class="acronym">GiST</acronym> 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,
<acronym class="acronym">GiST</acronym> combines extensibility along with generality, code
reuse, and a clean interface.
</p>
</div></body>
</html>
|
