For clarity we omitted the coalesce function calls which would be needed to
find rows that contain NULL in one of the
two fields.

Although these queries will work without an index, most
applications will find this approach too slow, except perhaps for
occasional ad-hoc searches. Practical use of text searching usually
requires creating an index.

Notice that the 2-argument version of to_tsvector is used. Only text search functions
that specify a configuration name can be used in expression indexes
(Section 11.7). This is
because the index contents must be unaffected by default_text_search_config.
If they were affected, the index contents might be inconsistent
because different entries could contain tsvectors that were created with different text search
configurations, and there would be no way to guess which was which.
It would be impossible to dump and restore such an index
correctly.

Because the two-argument version of to_tsvector was used in the index above, only a
query reference that uses the 2-argument version of to_tsvector with the same configuration name will
use that index. That is, WHERE
to_tsvector('english', body) @@ 'a & b' can use the index,
but WHERE to_tsvector(body) @@ 'a & b'
cannot. This ensures that an index will be used only with the same
configuration used to create the index entries.

It is possible to set up more complex expression indexes wherein
the configuration name is specified by another column, e.g.:

where config_name is a column in the
pgweb table. This allows mixed
configurations in the same index while recording which
configuration was used for each index entry. This would be useful,
for example, if the document collection contained documents in
different languages. Again, queries that are meant to use the index
must be phrased to match, e.g., WHERE
to_tsvector(config_name, body) @@ 'a & b'.

Another approach is to create a separate tsvector column to hold the output of to_tsvector. This example is a concatenation of
title and body,
using coalesce to ensure that one
field will still be indexed when the other is NULL:

SELECT title
FROM pgweb
WHERE textsearchable_index_col @@ to_tsquery('create & table')
ORDER BY last_mod_date DESC
LIMIT 10;

When using a separate column to store the tsvector representation, it is necessary to create a
trigger to keep the tsvector column current
anytime title or body changes. Section
12.4.3 explains how to do that.

One advantage of the separate-column approach over an expression
index is that it is not necessary to explicitly specify the text
search configuration in queries in order to make use of the index.
As shown in the example above, the query can depend on default_text_search_config. Another advantage is
that searches will be faster, since it will not be necessary to
redo the to_tsvector calls to verify
index matches. (This is more important when using a GiST index than
a GIN index; see Section
12.9.) The expression-index approach is simpler to set up,
however, and it requires less disk space since the tsvector representation is not stored explicitly.