exploysИндекс создан, но использоваться не сможет. Поэтому хоть обсоздавайся индексов, без HASH JOIN ты тот запрос будешь выполнять до морковкеного заговенья. Именно потому, что таблицы не отсортированы, слишком велики и не помещаются в памяти. ?
А при чем тут я? Это у Вас:
"Если есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP. Тогда и не было бы смысла в HASH JOIN в принципе."

Или это не Вы писали?

А я про отмену индексами HASH JOIN ниче не говорил.

Так что это Вы сами себя типа спросите.



exploys Рекурсия хэша возникает, когда входные данные не помещаются в доступную память , что приводит к разбиению их на несколько отдельно обрабатываемых секций. Если какая-либо из этих секций все же не помещается в доступную память, она разбивается на подсекции, которые также обрабатываются отдельно. Процесс разбиения продолжается, либо пока все секции не будут помещаться в доступную память, либо пока не будет достигнут максимальный уровень рекурсии

Ну хорошо, долго рекурсия продолжается.
А там еще могут быть переполнения раздела.

exploysЕсли укажите хинт MERGE JOIN,

Ну я укажу хинт, если потребуют гарантировано "обойтись" без HASH JOIN. Каков был вопрос, таков был ответ.

exploysто пойдет сортировка - самая тяжелая операция.
Таблицы не помещаются в памяти - значит сортировка будет происходить с использованием temp сохраняемого на диск. Вы представляете что это такое?
Вы когда-нибуть видели планы и их стоимость при использовании SORT IN TEMP?

Ну хорошо. Не помещаются. Temp - это уже Ваши там какие-то МS дела.

Оценку для сортировки, думау, по книжному примерно: 27*100000000 для одной таблы, а оценку соединеиия двух как сумму.

Самой тяжелой операцией по старинке считаю соединение.

Можно, конечно, надыбать и формулы для Хэш. И там есть лучшие и худьшие предположения.

А вот если одна табла поместилась в память, то, думау, ценка: 3* на сумму болков обоих табл. Это превзойти сложно, хотя слияние отсортированных это просто сумма блоков обоих табл.

Для больших табл, возможно, отклонения оценок от реальных цифр могут быть значительными.

Так или иначе, думаю, оставться на консервтивных позициях в этих вопросах все еще уместно: т.е. надо смотреть в кажном конкретном случае.
Но если в условиях соединение не эквивалентность, то думау, Хэш, скорее всего, в проигрыше.

exploysvadiminfoНу хорошо. Не помещаются. Temp - это уже Ваши там какие-то МS дела.

Ааа, у нас в MS. Вопросов больше не имею.


Короче топик про хэширование, предлагаю больше не офтопить леваком.
Ну к Вам в "принципе" вопросов
не может быть после Ваших гипотез типа
"Если есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP. Тогда и не было бы смысла в HASH JOIN в принципе."

А чтобы не было "леваков" к МСу, постите подобные мыстли, плиз, в своей СУБД или на крайняк в ПТ.

exploysvadiminfo, даже жаль немного тебя

Это не мои гипотезы, это цитаты из документации.

NESTED LOOP
авторСоединение вложенных циклов является особенно эффективным в случае, когда внешние входные данные сравнительно невелики , а внутренние входные данные велики и заранее индексированы.

MERGE
авторСоединение слиянием — очень быстрая операция, но она может оказаться ресурсоемкой, если требуется выполнение операций сортировки .


Это да, это не Ваше. Это все давно известное и избитое.

А у Вас гипотеза новяк:
"Если есть индексы по обоим полям то применялось бы всегда MERGE или NESTED LOOP. Тогда и не было бы смысла в HASH JOIN в принципе."
У Вас там и ранее было, что HASH JOIN применяется тока када нет индексов.
Возможно, Вы не видите разницы (связи в буквах опять не так установили), но она есть. Вы как бы все подготовили, чтобы "обходиться" без HASH JOIN.
А они нет. Ниче для этого не сделали.

Ivan DurakИнтересный вопрос. Все упирается в принципе в вопрос что быстрее - построение хэш-таблицы или сортировка (при мердже вроде как даже обе таблицы сортируются). В принципе не знаю как может быть сортировка быстрее, только если она каким-то образом меньше памяти требует.
Число чтений при Сортировке оценивается число блоков умножить на логарифм числа блоков.
Слияние двух табл просто сложение (т.е. если отсортировано ты быстрее в 3 хеша). Стало быть сумма с логарифмами. Хешироваание если в памяти, то это утроенная сумма кол-ва блоков, а слияние сортировкой по прежнему с логарифмами. Ясно что в реальности это достаточно частый случай. Но если не помещается в памяти, то возникают рекурсии. Кроме того наскока помню оценки хэш достаточно сильно ухудшаются есче и оптимистичны: делается предположение что нет переполнения разделов. В любом случае оценки очень грубые. Конечно, в СУБД там алгоритмы всячески типа улучшаются в сранении с тем, что нам читали в лекциях. Если в условиях соединения не равенства, то хэш вроде вообще не рекомендуют.
Даже в тут приводимых цитатах, людей верящих в преимущества хэша, производили МС пишут: "может оказаться", а не "обязательно оказывается". Потому я и думау, что если меньшая табла достаточно веллика, то, скорее всего, просто надеяться на хэш было бы чрезмено торопливо.

exploysvadiminfoпропущено...


Ну хорошо. Не помещаются. Temp - это уже Ваши там какие-то МS дела .

Великий и могучий ораклоид. С такими завялениями вот по ссылкам спорить идите.
temp сортировка
Не используется temporary tablespace
авторtemporary tablespace используется исключительно для выполнения сортировок, которые нельзя выполнить в памяти, и для хранения глобальных временных таблиц. Поэтому на быстродействии отсутствие врем. табл.простр. сказаться уж никак не может. Проблема не в них.
И на металинке сами ищите.
С какой стати мне то это искать? Все источники оценивают алгоритмы в количестве чтений с диска. Нас так учили.
У Вас были траблы как Вы думаете с Temp (а на самом деле мож там Касперский все тормозил), ну так Вы и ходите там везде и спрашивайте, спорте. Ваше авторитет еще не досточен, чтобы отказываться от общепринятых подходов. Вы можете там и две строки месяц сортировать. Что теперь все книжки из-за этого переписывать?

Ivan DurakА почему далеко не всегда оптимизатор выбирает мерж (а выбирает хэш) когда идет простое соединение по индексированным столбцам?
Возможно, потому что индксированность столбцов и их отсортированность не одно и то же. При соединении нуно считать всю таблу, скорей всего. А зараз считавется нескока блоков. А в случае индексов, тока один блок данных и к тому же как минмум один индекса.

т.е. один блок данных за два считывания. Это конечно вопрос реализации СУБД и от версии к версии меняется. Но и оптимизаторы в разных версиях СУБД могут выбирать разные планы.

exploysУ тебя галлюцинции, у меня никаких траблов с Temp никогда не было. А над Касперским на серваке СУБД - спасибо повеселил.
Теперь авторитеты начали искать? Для тебя и здравый смысл не авторитет и металинк, бол и уважаемые люди из раздела Oracle данного форума. И книжек вы не читали. И про Temp Tablespace в Oracle ничего не слышали и сортировку в нем. Вы делитант.
Для неучей вы может и покажетесь умным, для образованных вы останетесь делитантом.
Я не знаю с чего Вы взяли, что Ваша оценка моих знаний очень важна, и это что-то может изменить. Тем более, что Вы же не производите впечатление кого-то уважаемого. Возможно, Вы просто на что-то там обиделись. Мало ли.
Что до алгоритмов, то пока все еще для оценки этих алгоритмов в литературе используют кол-во считывний блоков. Вроде формул в которых есть ТЕМП не попадалось.