"tbh" <femdev@newsgroups.nospam> wrote in message
news:OKixD4G$HHA.5404@TK2MSFTNGP02.phx.gbl...
> 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
>
>