Re: tsearch2 in PostgreSQL 8.3? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: tsearch2 in PostgreSQL 8.3?
Date
Msg-id 5459.1187190873@sss.pgh.pa.us
Whole thread Raw
In response to Re: tsearch2 in PostgreSQL 8.3?  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:
> ISTM that the functional index would be considerably smaller than the
> additional column approach, since tsvectors can be quite long. That
> seems like a very desirable thing with larger textbases. However,
> without an additional column certain queries would not be possible, such
> as IndexScans on a non-text search index with an additional filter on
> text search. So each way would be desirable in different situations.

Huh?  Of course you can do the searching without an additional column;
you just have to compute the tsvector on-the-fly at each row.  This is
a straight trade of more CPU cycles for less I/O.

> Would it be wrong to allow both approaches?

Nobody has suggested disallowing the trigger approach (indeed it's hard
to see how we could).  The argument is mostly about how to make a
functional index approach work conveniently; and secondarily about
what's needed to make dump/restore reliably reproduce the current
database state, whichever approach you choose.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions]
Next
From: Decibel!
Date:
Subject: Re: is this trigger safe and efective? - locking (caching via triiggers)