There are two kinds of indexes that can be used to speed up
full text searches. Note that indexes are not mandatory for full
text searching, but in cases where a column is searched on a
regular basis, an index is usually desirable.

CREATE INDEX name ON table USING gist(column);

Creates a GiST (Generalized Search Tree)-based index.
The column can be of
tsvector or tsquery type.

CREATE INDEX name ON table USING gin(column);

Creates a GIN (Generalized Inverted Index)-based index.
The column must be of
tsvector type.

There are substantial performance differences between the two
index types, so it is important to understand their
characteristics.

A GiST index is lossy, meaning that
the index may produce false matches, and it is necessary to check
the actual table row to eliminate such false matches.
(PostgreSQL does this
automatically when needed.) GiST indexes are lossy because each
document is represented in the index by a fixed-length signature.
The signature is generated by hashing each word into a single bit
in an n-bit string, with all these bits OR-ed together to produce
an n-bit document signature. When two words hash to the same bit
position there will be a false match. If all words in the query
have matches (real or false) then the table row must be retrieved
to see if the match is correct.

Lossiness causes performance degradation due to unnecessary
fetches of table records that turn out to be false matches. Since
random access to table records is slow, this limits the
usefulness of GiST indexes. The likelihood of false matches
depends on several factors, in particular the number of unique
words, so using dictionaries to reduce this number is
recommended.

GIN indexes are not lossy for standard queries, but their
performance depends logarithmically on the number of unique
words. (However, GIN indexes store only the words (lexemes) of
tsvector values, and not their weight
labels. Thus a table row recheck is needed when using a query
that involves weights.)

In choosing which index type to use, GiST or GIN, consider
these performance differences:

GIN index lookups are about three times faster than
GiST

GIN indexes take about three times longer to build than
GiST

GIN indexes are moderately slower to update than GiST
indexes, but about 10 times slower if fast-update support was
disabled (see Section 54.3.1
for details)

GIN indexes are two-to-three times larger than GiST
indexes

As a rule of thumb, GIN
indexes are best for static data because lookups are faster. For
dynamic data, GiST indexes are faster to update. Specifically,
GiST indexes are very good for
dynamic data and fast if the number of unique words (lexemes) is
under 100,000, while GIN
indexes will handle 100,000+ lexemes better but are slower to
update.

Note that GIN index build
time can often be improved by increasing maintenance_work_mem,
while GiST index build time is
not sensitive to that parameter.

Partitioning of big collections and the proper use of GiST and
GIN indexes allows the implementation of very fast searches with
online update. Partitioning can be done at the database level
using table inheritance, or by distributing documents over
servers and collecting search results using the dblink module. The latter is possible because
ranking functions use only local information.