Имеет ли смысл создавать индекс по timestamp column?
Никак не могу понять ускоряет ли это процесс для incremental обновления?

Создал full-text каталог, выполнил Full population.
Таблица имеет timestamp поле, даже индекс создал по этому полю.
Ничего не меняю - запускаю Incremental population - по идее все должно завершиться мгновенно, а на самом деле процессор занят на 100% и выполнение занимает столько же времени как и в случае full population - вопрос - а чем же он занят??? Изменений же вообще не было ...

Т.е. он что тупо перебирает всю таблицу? Так для таблиц с миллионами записей он вечно этим заниматься будет. Черт - последний раз пытался full-text indexing год назад использовать - плюнул, сейчас вот снова идея возникла - ну опять все через задницу, похоже, сделано.

Есть у кого-нибудь практический опыт работы с этим безобразием?

Продолжаю задавать вопросы о full-text indexing - с грехом пополам заработали индексы, теперь вот воюю с поиском.

Задача: есть таблица с двумя полями, включенными в full-text индекс, я хочу выбрать записи, содержащие два слова: LG и keeper. Проблема: если я использую для вбора CONTAINS(*,'LG keeper') то выбираются записи, в которых ОБА эти слова содержатся в ОДНОМ поле, записи в которых одно слово в одном поле, а другое в другом - не выбираются. Если использую FREETEXT(*,'LG keeper') то нужные мне записи выбираются, но также выбираются записи, содержажщие хотя бы одно слово хотя бы в одном из полей.

Как можно выбрать только те записи, которые содержат необходимые мне слова в любом поле - в том числе в разных полях.

Или я так и буду в этой ветке сам с собой общаться?

OR - не подходит, так как мне нужно AND - а вот работает этот самый AND только если оба слова в одной колонке, если в одной записи, но в разных колонках - хрен Вам (это в случае CONTAINS, FREETEXT выбирает записи, содержащие хотя бы одно слово, потому наверное и зовут FREE...). Т.е. в одном случае нужные записи не выбираются, а в другом выбирается много лишних. Можно, конечно, по рангу сортировать, но лучше бы без лишних.

О timestamp - не понял к чему Вы это - наверное, к incremental update?
Так я Вам совершенно конкретно заявляю - если у Вас есть таблица с 10 000 000 записей, и вы изменили ОДНУ запись, то при incremental update SQL Server будет сканировать ВСЕ 10 000 000 записей, будет проверять timestamp в КАЖДОЙ записи и для измененных записей будет обновлять full-text index - займет это все "всего лишь" пару часов. Удобно, правда? Я даже знаю почему он так поступает - timestamp хорош при изменениях, а вот что делать если Вы удалили запись? timestamp - то Вы тоже удалили. Хотя incremental full-text index update сейчас для меня не проблема - в SQL2K появился еще один механим, позволяющий изменять full-text индексы в реальном времени, timestamp, кстати, для этого не нужен..

Так что спасибо за советы, но они не помогли. Может еще идеи есть?

А язвить не стоит - я с SQL Server'ом с 93-го года работаю (с 4.21a) - так что BOL читал .

Да вобщем-то можно так запрос построить, но запрос генерится клиентским приложением, поэтому не хотелось бы вносить изменения в приложение если мы третье поле, например, в full-text indexing добавим.

В том-то и проблема, что если одно поле содержит LG, а другое keeper - то Ваш запрос ничего не вернет - CONTAINS работает только если ВСЕ слова содержатся в ОДНОМ поле - в этом и заключается моя проблема.