Доброго времени суток!
Sergey Mereutsa wrote:
Нифига, тут есть товарищи, которые курят куда более тяжелую траву :))
За полетом их мысли я даже следить не пытаюсь :)
Правильно. Но я исходил из того соображения, что количество записей в
"виртуальной" таблице, с которой происходит объединение - несравнимо
мало, по сравнению с таблицей текстовых индексов - там ну от силы
десяток записей, а в индексах - 12 миллионов. Так что натурал по
rdb$database - это ну никак не тормоза. Вот натурал по индексной
таблице - это жжж.. :)
Да, "виртуальная" таблица - несомненно, красивое решение.
Но я имел в виду то, что order by 2 desc добавляет лишний SORT в план
Или результат объединения - всего лишь несколько записей, и SORT здесь
на быстродействие не повлияет?
Да, действительно. Я предположил, что может быть некоторое различие в
быстродействии между отбором через where во внешнем запросе и having в
derived table, не отражаемое в плане - было бы интересно узнать, не
домыслы ли это.
Вот тут надо к поставщикам тяжелых... медпрепаратов обратиться - к
Димам, Владу или Алексу :) Если они будут не заняты - мне тоже было бы
интересно узнать ответ. Хотя по логике - зачем серверу врать и делать
что-то, не отраженное в плане?
Было у меня смутное воспоминание, что какие-то операции в плане
не учитывались - видимо та, о которой говорил Дмитрий.
В этом случае и отбор записей, и сортировка идут по индексу - насколько
я помню, это нехорошо. Эта проблема недавно здесь обсуждалась - ветка
"странное время выполнения запроса" от Kochmin Alexandr.
Ну то обсуждение я видел, но прокомментировать не могу.
Собственно, теоретическое обоснование приводил Д. Кузьменко
(см ссылку в его посте от 03.07.2007 11:43).
Так вот интересно, если убрать сортировку по индексу, то сможет ли этот
вариант конкурировать с остальными двумя?
А как ее убрать? Рулить хинтом оптимизатору +0, как в твоем запросе?
Ну да. Альтернатива для эстетов - cross join rdb$database :)
Слегка переделанный запрос (только имена полей добавил, чтобы сервер
не ругался, тоже результат третьего исполнения):
Спасибо!
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
Т.е. ничем по сути не лучше - большее время запроса на пару мс не
считается, так как сейчас сервер реиндексирует базу с обновленным
словарем.
Ну количество чтений с диска все же поменьше, так что есть шанс, что
он обскачет Ваш первоначальный вариант :)
Кстати, что касается оптимизации запросов.
Правильно ли я понимаю, что Reads from disk характеризуют нагрузку
на дисковую подсистему, а Fetches from cache - на память и процессор?
Можно ли с уверенностью предсказать Execute time (или хотя бы
ранжировать их) на незанятом сервере, зная эти параметры?
В Вашем случае имеем
Ваш I II Iopt
Execute time = 764ms 2s 886ms 624ms X
Reads from disk
to cache = 17 542 15 229 8 801 11 335
Fetches from cache = 73 787 93 782 133 848 73 914
Думается все же, что X < 764, хотя зависимость неясна.
Интересно, сможет ли Iopt соперничать с II вариантом Влада Хорсуна при
возрастании числа ключевых слов?
С уважением, Евгений.
