Кщд   (18.02.10 11:51) [58]


> возможно, потому, что table access full хуже index unique
> scan в данном случае?)
> конкретно: 50 000 индексных чтений с NL лучше hash join
> с шестидесятимиллионной таблицей


прошу прощения, не соотнес твой пост с характеристиками таблиц из [45]

То есть, Кайт реабилитирован ?

>А практика говорит наоборот.
>Прикрутил хэш джойн и получил значительное ускорение.
возможно, оптимизатор сошел с ума?)
или баг
даже не заглядывая в план и не высчитывая стоимость запроса понятно, что эффективнее произвести 50 000 index unique scan
на 10.2.0.4 мне воспроизвести указанного Вами не удалось

>То есть, Кайт реабилитирован?
Кайт - душка навсегда, в чем лично я ни разу не сомневался)

> возможно, оптимизатор сошел с ума?)

У нашего оптимизатора давно крыша съехала. Хинтим все запросы. Пробовали собирать статистику - стало еще хуже. :)

Но это не в оптимизаторе дело - он то как раз нестед лупс и предлагает.

Это опыт - если в первой таблице записей >= 30 тысяч, то на нашей базе надо пускать фулл-скан по обоим.
Если меньше - экспериментируем.

> Кщд   (17.02.10 12:20) [56]


> >чаще всего размазаны по таблице.
> поясните, пожалуйста, подробнее, что имелось в виду?
> что плохого в этом случае?
> и если форин=FK, то какое отношение FK имеет к данному тест-
> кейсу?

тесткейс посмотрел невнимательно, припишем там

блок 8К допустим. запись - 80 байт допустим. В каждом блоке есть одна (ну несколько) запись(ей) с  FK=условие (FK размазан по таблице).  Вроде б "в индекс" попадает несколько процентов, клево все. Только один фиг прочитать надо ВСЮ таблицу, и не блок-за-блоком, в произвольном порядке.

>Petr V. Abramov ©   (25.02.10 22:31) [63]
укажите, пожалуйста, запрос полностью?
из вышеприведенного логика выбора hash join вместо nested loops не видна...
не понял, зачем читать таблицу, если можно обойтись только чтением индекса?