> Ok, but then it should be sufficient to recreate the txt2txtidx function
> and/or the index after a change of parser and dictionaries. So generally
> spoken, the index function approach to tsearch works, if you take care of
> that. I gladly recreate the function and/or index from time to time, if I
> can do without that additional column, bloated dump and slow trigger.
>
> This is very good news, as this is a very easy approach to having an easy
to
> use fulltextsearch in postgresql.
I talked a bit more with Oleg and Teodor about this index function approach
and we came to the conclusion that it is safe to use (if you take care of
the above), but it might be a bit slower than the original column based
approach. That it because the used operators are defined with RECHECK, and
with the index function approach the RECHECK is against an (expensive)
function instead of "raw" data in a column.
Btw. the "iscachable" has another advantage, it seems to really speed up the
search. I have done tests again 250000 entries, mostly nicknames based on
fantasy (so the english stemmer has not much to do), and the first search
for a name takes about 0.5 - 2.5 seconds whereas all subsequent searches for
the same name (even with fresh inserted data) take less than 0.1 seconds. Or
does this have nothing to do with "iscachable"?
Regards,
Bjoern
