hi, i've noticed that in our SQL 2000 systems fulltext search performance
suffers when one searches for a term that occurs frequently in the index.
(of course i realize that ultimately there is no way around this, but I have
some ideas i'd like to explore.)

in my system an extremely rough rule of thumb seems to be that my search
runs (again *very* roughly) 1 second per 1000 hits. so if a person searches
for a common term (that occurs many thousands of times) the search is likely
to time out. (searching for this term and another common term of course
speeds up the search and makes it more user friendly, not to mention more
likely to lead to a better result.) alas, the way full text search and joins
to indexed tables are combined, time-restricting a search (e.g. for items
only in the last month) doesn't seem to help speed up the search as much as
reducing the hits from the *contains* clause itself.

so i'm looking for ways to avoid bad search performance (from the website
user's perspective) and also perhaps to reduce robot-search-induced load and
have a couple questions:
- can i ask the full text search service how often a word is indexed? (this
could help me predict whether a search for a single term is likely to have
horrible results; maybe i could use it to take special measures.)
- is it possible (e.g. by triggers or registering a callback function or...)
to be notified when the index changes *with respect to a term* or a list of
terms? (that would be useful if one decided to cache search results for
frequent, expensive queries)

cheers,

Tim Hanson