On Tue, 2007-08-14 at 17:41 -0400, Tom Lane wrote:
> I've just finished re-reading the prior thread, and here are what seem
> to me to be the salient points:
>
> * Oleg, Teodor, and all of the old-line users of tsearch2 are
> comfortable with setting up a trigger to maintain a materialized
> tsvector column for a table. They argue that recomputing the tsvector
> (possibly more than once) during a query is more expensive than fetching
> it from disk. My suspicion is that the latter argument gets weaker
> every year --- CPUs are getting faster lots faster than disks are.
>
> * Bruce (and I ... not sure about anyone else) want to support usage of
> text search via a functional index. This is argued to be easier to set
> up (no fooling with triggers) and possibly faster depending on CPU vs
> I/O speeds. I don't think there is any desire here to eliminate the
> trigger approach, just to provide an alternative.
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.
Would it be wrong to allow both approaches? If there is strong
disagreement then it usually means both people are right.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com