ну и где же тут оптимальность его работы? два запроса, возвращающие одну и ту же запись, выполняются один быстрее, другой медленнее.
обоснуй, плиз, своё утверждение.

ты вот с этим
авторя так думаю, что сервер идёт по индексу и для каждой записи c itemid=1 (а их порядка 300) выполняет один и тот же подзапрос
согласен? если нет, объясни, где я неправ

авторНу нельзя же так тупить, ей богу !
туплю, кажися, не я :)

авторвложенный запрос выполняется СТОЛЬКО РАЗ, СКОЛЬКО ЗАПИСЕЙ в таблице itemvalues. - это ты погорячился.
сколько себя помню, всегда считал, что коррелированный подзапрос выполняется столько раз, сколько записей возвращает основной запрос

так что, борис - ты неправ

ну не может он выполняться для всех записей, не может. в таблице их больше 3 млн. Простой select count по этой таблице выполняется 3 сек, а этот меньше секунды. к тому же Perfomance Analysis показал, что было выполнено 100 с лишним тысяч чтений индекса, но никак не 3 млн и не NATURAL, если бы эта ботва выполнялась для ВСЕХ записей из таблицы.

авторТы говоришь про общую голую теорию безотносительно какого "типа" вложенный запрос.
а коррелированные подзапросы бывают разных типов?

авторНо если ты хочешь "подогнать" под неё, считай "столько раз, сколько записей возвращает основной запрос", в данном случае = сколько записей в таблице.
уточняю ещё раз: оба запроса (с коррелированным и некоррелированным подзапросами) возращают ОДНУ запись, ОДНУ! а не все 3 млн.

такое ощущение, что мы о разных вещах говорим.
ладно, Johnmen, давай по-другому.
вот тебе запрос:

select iv.ivalue, iv.ondate from itemvalues iv
where iv.itemid=1 and iv.ondate=
(select max(ondate) from itemvalues
where itemid=iv.itemid and ondate<='1.1.2005')

а теперь, если тебе не сложно, объясни мне алгоритм, по которому сервер формирует результирующий набор данных (желательно в терминологии бд).
я не исключаю, что меня переклинило: в таком случае ткни меня, плиз, носом
в этот клин, за что буду тебе весьма благодарен

2mv: спасибо, я уже просёк, что от тебя ничего конструктивного не дождёшься

ну наконец-то

автордля внешнего запроса сканируется индекс IV_IDX для условия iv.itemid=1. это даёт не 1-у запись, а много больше
на самом деле это даёт одну запись, хотя перебирает он их все в процессе сканирования индекса(их у меня 355 для itemid=1)

ну а дальше
автордля каждой полученной записи выполняется кореллированный подзапрос
и фильтрует их по условию iv.ondate = (select max(ondate) ...
вот о чём я и говорю: он 355 раз выполняет один и тот же подзапрос.
355*355=126025. аналайзер показал 126380 чтений индекса - как раз где-то так и выходит. порядка 300 чтений серверу надо чтобы по дереву добраться до itemid=1.

авторПроблемы оптимизатора в том, что он не понимает того, что подзапрос на самом деле не кореллированный, т.е. не комбинирует условие корелляции itemid=iv.itemid с условием внешнего запроса iv.itemid=1. Не уверен, что он
должен это делать ;)
получается, что проблемы таки есть. то бишь оптимизатор не оправдывает возложенных на него надежд. собственно, проверять коррелированный подзапрос на некоррелированность от него и не требуется.
нужно всего лишь проверить, изменились ли параметры для вложенного подзапроса при переборе записей основного, и выполнять подзапрос только в том случае, если изменение имело место. а так получается мартышкин труд.
так это у меня и данных-то немного, а положим что их количество вырастет в несколько раз - так тут такие тормоза начнутся, что мама не горюй

JohnmenУчти в своих рассуждениях ещё один существенный в данном случае момент.
Булево выражение вычисляется не слева-направо, а справа-налево.
а это здесь каким боком?

ничего не поменялось - всё по-прежнему. а какие тут могут быть проблемы?