|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Друзья, возник вопрос касательно hj и nl. Гугление и опрос людей в коллективе поражает разные мнения и неочевидные выводы. Собственно сабж Будет ли работать hj когда ни одна из таблиц не помещается в память? Как оракул будет выполнять такой запрос? Включит nl? Какие могут быть ситуациикогда nl окажется быстрее hj? Из ответов от своих коллег - hj всегда, ну или на 90% всегда быстрее и эффективнее. Зависимость от индексов и сективности. Когда к большой таблице присоединяется мелкая nl эффективнее и т.д. Все ответы наверняка справедливы и правильные, но все же вопрос из собеседования, оппонент ожидал ответ «если ни одна из таблиц не помещается в памяти hj работать не будет вообще», так ли это? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.10.2019, 22:41 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Есть такая вьюха - V$PGA_TARGET_ADVICE_HISTOGRAM как думаешь что значат поля estd_onepass_executions, estd_multipasses_executions? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 02:44 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
кит северных морей 14840489 такая же вода, без явного определения и ответа. Вообще чел спрашивает - верны ли его суждения? Про dwh, мой коллега говорит что там всегда только hj, и он правильно говорит. Но тогда какого хрена я уже 3-й раз нахожу - если одна из таблиц помещается в ram. Да ни одна не помещается, и что? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 07:08 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Хуже того, про память я везде натыкаюсь как на условие для hj, одна из таблиц должна вся помешаться в память, ну и не поместилась и что? Ну запишется на диск. Хоть и дали мне ответ, тогда nl отработает вместо hj, я в это не верю и для меня это неочевидно. Вложенный цикл в таких условиях будет отрабатывать просто вечно и весь dwh должен на nl работать - но это же бред. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 07:26 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Vivat!SanЕсть такая вьюха - V$PGA_TARGET_ADVICE_HISTOGRAM как думаешь что значат поля estd_onepass_executions, estd_multipasses_executions? Давай жги! Что означает? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 07:29 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Vivat!Sanчто значат ... estd_Yesterday? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 07:42 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrХуже того, про память я везде натыкаюсь как на условие для hj, одна из таблиц должна вся помешаться в памятьВезде натыкаться не нужно. Есть всего один почти достоверный источник - это документация и там про when the hash table does not fit entirely in the PGA есть упоминания. "Хуже того", с merge join, order by, group by все то же самое. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 07:54 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
ElicYesterday?all my troubles seemed so far away... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 08:29 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometr, Это ты жги, наводку тебе дал куда копать. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 08:56 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
-2-golovonometrХуже того, про память я везде натыкаюсь как на условие для hj, одна из таблиц должна вся помешаться в памятьВезде натыкаться не нужно. Есть всего один почти достоверный источник - это документация и там про when the hash table does not fit entirely in the PGA есть упоминания. "Хуже того", с merge join, order by, group by все то же самое. И? Каков ответ? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 11:06 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrИ? Каков ответ?42 ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 11:15 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
ElicgolovonometrИ? Каков ответ?42 Отличный мудацкий ответ! ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 11:27 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrтакая же вода, без явного определения и ответа. Вообще чел спрашивает - верны ли его суждения? прочитайте не только то сообщение, на которое я дал ссылку, но и ответы на него. там есть есть очень подробный разбор HJ, в т.ч. ссылка на ноту с white paper, в котором всё разжевывается практически побайтово. документ старый, но для общего понимания происходящего сойдёт. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 11:50 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometr-2-пропущено... Везде натыкаться не нужно. Есть всего один почти достоверный источник - это документация и там про when the hash table does not fit entirely in the PGA есть упоминания. "Хуже того", с merge join, order by, group by все то же самое. И? Каков ответ? мда. docs.oracle.comHow Hash Joins Work When the Hash Table Does Not Fit in the PGA The database must use a different technique when the hash table does not fit entirely in the PGA. In this case, the database uses a temporary space to hold portions (called partitions) of the hash table, and sometimes portions of the larger table that probes the hash table. golovonometrно все же вопрос из собеседования, оппонент ожидал ответ «если ни одна из таблиц не помещается в памяти hj работать не будет вообще», так ли это? нет, не так. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 12:15 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
кит северных морейgolovonometrпропущено... И? Каков ответ? мда. docs.oracle.comHow Hash Joins Work When the Hash Table Does Not Fit in the PGA The database must use a different technique when the hash table does not fit entirely in the PGA. In this case, the database uses a temporary space to hold portions (called partitions) of the hash table, and sometimes portions of the larger table that probes the hash table. golovonometrно все же вопрос из собеседования, оппонент ожидал ответ «если ни одна из таблиц не помещается в памяти hj работать не будет вообще», так ли это? нет, не так. Отлично. Значит оппонент не прав, и hj работать будет. Тогда только остался только один вопрос, где же nl проявит себя лучше? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 12:49 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrТогда только остался только один вопрос, где же nl проявит себя лучше?Юноша, да Вам что в лоб что по лбу. При такой дерзости и неспособности думать дорога в манагеры. Последняя попытка, супер конерктный пример Код: plsql 1. 2. 3. 4. 5. 6.
Код: plsql 1. 2. 3. 4. 5.
Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Хватит мозгов сделать выводы по приведённым табличкам или всё равно надо разжевать? PS. У Hash Join ограниченная область приминения. Он может быть использован только для equi join predicates. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 13:35 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrгде же nl проявит себя лучше? Если коротко, то в oltp. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 16:25 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Кобанчег, мега респект! Спасибо большое, значит оппонент прав. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 18:42 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometrКобанчег, мега респект! Спасибо большое, значит оппонент прав.вам продемонстрировали выигрыш NL в случае наличия эффективного индексного доступа к присоединяемой таблице. как вы и просили. к теории вашего оппонента это не имеет никакого отношения. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 20:14 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
golovonometr Будет ли работать hj когда ни одна из таблиц не помещается в память? Как оракул будет выполнять такой запрос? Включит nl? сначала прочёл, как говнометр, простите будет. по частям: берётся большая таблица и её часть, сколько влезет в память, сравнивается со второй, потом берётся из второй часть, сравнивается с остатком из первой и так ступенькой, большими кусками отщипывая, будет двигать весь объём (обычно это экстремальное решение, когда в базе трэш и никто не удосужился провести аудит типовых запросов и создать индексы под них), но так бывает и оракл умеет с этим работать. нет: все равно выгодней hj, даже так через жопу, завесив весь объём памяти базы - тупо быстрее и меньше операций с блоками ps: Андрею респект - единственный практик в этом треде (без голой теории на примерах). только практика выветривает из башки всю теоретическую блажь... головоногометр, бери с него пример - у него есть чему поучиться ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 22:36 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Fogelнет: все равно выгодней hj, даже так через жопу, завесив весь объём памяти базы - тупо быстрее и меньше операций с блоками Кто тебе даст весь объём памяти сервера? О какой области памяти речь хоть понимаешь? практик тут нашёлся ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 22:51 |
|
Hash join на больших таблицах
|
|||
---|---|---|---|
#18+
Fogelпо частям: берётся большая таблица и её часть, сколько влезет в память, сравнивается со второй, потом берётся из второй часть, сравнивается с остатком из первой и так ступенькой, большими кусками отщипывая, будет двигать весь объём Личные фантазии имело бы смысл излагать, если обладаешь литературно-алгоритмическим талантом. Только теребонькать свой эпистолярий нужно было до указания на наличие описания алгоритма в документации. Fogelникто не удосужился провести аудит типовых запросов и создать индексы под нихналичие подходящего индекса способстсвует nested loop, но не обязательно делает его эффективнее hash join. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.10.2019, 23:43 |
|
|
start [/forum/topic.php?fid=52&msg=39873826&tid=1882002]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
69ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 18ms |
total: | 188ms |
0 / 0 |