Привет!
>> Это публичная конференция, тут каждый сам решает - присоединяться к
>> ветке или нет. :)
> Просто Ваша задача существенно превосходит мой уровень - решил немного
> самообразованием заняться :)
Нифига, тут есть товарищи, которые курят куда более тяжелую траву :))
>> "order by 2 desc" - сортировка по второму полю (количество ключевых
> Сначала так и подумал, потом усомнился - ведь Вы же количество считаете
> и к оптимизации стремитесь. Начали мелкать мысли по поводу sort-buffer и
> cursor stability - и под конец совсем запутался :)
Правильно. Но я исходил из того соображения, что количество записей в
"виртуальной" таблице, с которой происходит объединение - несравнимо
мало, по сравнению с таблицей текстовых индексов - там ну от силы
десяток записей, а в индексах - 12 миллионов. Так что натурал по
rdb$database - это ну никак не тормоза. Вот натурал по индексной
таблице - это жжж.. :)
>> Правильно. Но первый вариант мне почему-то нравится больше и order by
>> 2 desc тут не смотрится
> Да, действительно. Я предположил, что может быть некоторое различие в
> быстродействии между отбором через where во внешнем запросе и having в
> derived table, не отражаемое в плане - было бы интересно узнать, не
> домыслы ли это.
Вот тут надо к поставщикам тяжелых... медпрепаратов обратиться - к
Димам, Владу или Алексу :) Если они будут не заняты - мне тоже было бы
интересно узнать ответ. Хотя по логике - зачем серверу врать и делать
что-то, не отраженное в плане?
>>
>> Запрос с IN(), как я показал - в моем случае тормознутее :))
> План
> PLAN JOIN (SORT (IDX W ORDER FK_T_SEARCH_WORDS_1 INDEX
> (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1)), D
> INDEX (PK_T_DOCUMENTS))
> В этом случае и отбор записей, и сортировка идут по индексу - насколько
> я помню, это нехорошо. Эта проблема недавно здесь обсуждалась - ветка
> "странное время выполнения запроса" от Kochmin Alexandr.
Ну то обсуждение я видел, но прокомментировать не могу.
> Так вот интересно, если убрать сортировку по индексу, то сможет ли этот
> вариант конкурировать с остальными двумя?
А как ее убрать? Рулить хинтом оптимизатору +0, как в твоем запросе? О
результатах - ниже. ;-)
> select count(1) from t_documents d,
> (select w.document_id+0 from
> t_search_words w
> where w.lang_id=2 and w.flag=1
> and w.word in (2624961196, 1902388292, 1228066714)
> group by 1
> having Count(1) = 3) idx
> where d.lang_id=2
> and d.published_when>='01.07.2002'
> and d.published_when<='02.07.2007'
> and d.publisher_id =36149
> and d.id=idx.document_id
> Если интересно, просьба сравнить в быстродействии.
Слегка переделанный запрос (только имена полей добавил, чтобы сервер
не ругался, тоже результат третьего исполнения):
select count(1) as cnt from t_documents d,
(select w.document_id+0 as doc_id from
t_search_words w
where w.lang_id=2 and w.flag=1
and w.word in (2624961196, 1902388292, 1228066714)
group by 1
having Count(1) = 3) idx
where d.lang_id=2
and d.published_when>='01.07.2002'
and d.published_when<='02.07.2007'
and d.publisher_id =36149
and d.id=idx.doc_id
Plan
PLAN JOIN (SORT (IDX W INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1,
T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS))
Adapted Plan
PLAN JOIN (SORT (IDX W INDEX (T_SEARCH_WORDS_IDX1, T_SEARCH_WORDS_IDX1,
T_SEARCH_WORDS_IDX1)), D INDEX (PK_T_DOCUMENTS))
Prepare time = 203ms
Execute time = 780ms
Avg fetch time = 780,00 ms
Current memory = 67 378 548
Max memory = 78 021 200
Memory buffers = 4 000
Reads from disk to cache = 11 335
Writes from cache to disk = 0
Fetches from cache = 73 914
Т.е. ничем по сути не лучше - большее время запроса на пару мс не
считается, так как сейчас сервер реиндексирует базу с обновленным
словарем.
Я тут другую хрень обнаружил - об этом в соседней ветке.
--
Best regards,
Sergey mailto:[EMAIL PROTECTED]
