|
|
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
hi all Дано: LI-T3.0.0.30889 Код: sql 1. 2. 3. Вот два варианта одного и того же запроса, в котором NOT IN() лезет в выборку, содержащую в одной из записей NULL (след-но, итоговая выборка должна быть пустой): var-1 Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Его статистика однозначно говорит, что ФБ прекратил сканровать 'c' сразу после того, как наткнулся на NULL-строку: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. var-2. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Статистика показывает, что ФБ парился вплоть до последней записи: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Пытаемся подправить дело, принудительно заставив ФБ упорядочить выборку 'c' так, чтобы NULL-строка оказалась первой: var 2b. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. var 2c. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Для обоих вариантов (2b & 2c) - увы, ничего не взлетает: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. И еще. Если заменить row_number() на само поле 't.i': Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. - то статистика станет лучше, фетчей меньше на пол-ляма (хотя всё равно идёт туго): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. И на довесок: order by i nulls first оказывает вообще какое-то губительное воздействие, даже если в выборке 'c' строку с null'ом засадить первой, как в var-1 : Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Trace: Код: plaintext 1. 2. 3. 4. 5. В общем, я не понял что-то: order by i nulls first - он же должен выполниться мгновенно (там 500 строк всего). СТЕшка 'c', следовательно, должна поступить на вход в финальный запрос уже отсортированная, причём в ней первой записью будет NULL. Что тогда мешает ФБ выполнять все разновидности var-2 так же быстро, как var-1 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 13:59:15 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Кстати, если затолкать в таблицу 't' побольше строк: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. - видно, что hash join идёт вровень по времени с merge join'ом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. == vs 2.5 == Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. В статистике не хватает сведений о других расходах при HJ. 2 dimitr / hvlad : это можно будет устранить в альфа/бете/гамма/дельте-3.x ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 14:18:15 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
ТаблоидВот два варианта одного и того же запроса, в котором NOT IN() лезет в выборку, содержащую в одной из записей NULL (след-но, итоговая выборка должна быть пустой): думал над этой фразой и решил проверить запрос авторwith c(n) as( select null from rdb$database union all select 2 from rdb$database union all select 3 from rdb$database ) select count(*) as q from rdb$database where 1 not in (select n from c); даёт план Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. по мне так довольно странный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 14:33:31 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Пока все молчат, буду говорить дальше :-) Добавляю индекс: Код: sql 1. Запускаю: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. В обоих версиях план = NL. Но ФБ-3 проигрывает: он делает ДВЕ сортировки (почему, кстати ?) и на 8 млн больше фетчей trace 3.0 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. trace 2.5 Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 14:37:13 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Симонов Дениспо мне так довольно странныйне увидел твой ответ: ога, я тоже обратил внимание, что там последним еще и union выполняться начинает: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 14:41:25 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
ТаблоидНо ФБ-3 проигрывает: он делает ДВЕ сортировки (почему, кстати ?) и на 8 млн больше фетчей что-то странно. По приведённому тобой плану в 2.5 сортировки нет вовсе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 14:44:49 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Симонов ДенисПо приведённому тобой плану в 2.5 сортировки нет вовсеЧто-то поменялось с not in(). var-1. Код: sql 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. var-2. Код: sql 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:26:25 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Таблоид, судя по этому плану Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Второй сортировки там таки нет. Просто она неверно прорисовывается. Здесь тоже RDB$DATABASE вырисовывается 6 раз. Не понимаю почему не 3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:33:26 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
занеси себе в голову, что: - сортировка ничего не возвращает наружу, пока не отсортирует весь входной поток - NOT IN выполняется для каждой записи тогда ты поймешь, чтобы твой запрос выполняет как минимум 500 сортировок по 500 записей ЗЫ. будете продолжать валить кучу несвязанных вопросов в один топик - не буду даже пытаться разбираться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:34:58 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
для запроса Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. план уже такой Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:36:57 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
сначала пишем UNION DISTINCT , а потом удивляемся, а откуда там сортировка... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:39:34 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
dimitrзанеси себе в голову, что: - сортировка ничего не возвращает наружу, пока не отсортирует весь входной поток - NOT IN выполняется для каждой записи тогда ты поймешь, чтобы твой запрос выполняет как минимум 500 сортировок по 500 записей ЗЫ. будете продолжать валить кучу несвязанных вопросов в один топик - не буду даже пытаться разбираться хорошо. Тогда почему для with c(n) as( select null from rdb$database union all select 2 from rdb$database union all select 3 from rdb$database ) select count(*) as q from rdb$database where 1 not in (select n from c); план не такой Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:41:25 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, потому что NOT IN уже давно трансформируется в два (или три, не помню) подзапроса, чтобы он мог использовать индексы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 15:47:27 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
dimitr, можно поподробнее. А то в статье по методам доступа этого не увидел вот такой запрос Код: sql 1. 2. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. зачем здесь Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 16:02:00 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
dimitrзанеси себе в голову, что: - сортировка ничего не возвращает наружу, пока не отсортирует весь входной поток - NOT IN выполняется для каждой записи тогда ты поймешь, чтобы твой запрос выполняет как минимум 500 сортировок по 500 записейБудет ли материализация результатов подзапросов, которая вроде как грядёт в скором времени в ФБ-3, распространена также на то, что внутри [not] in( ... ) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 17:37:18 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Симонов Денисзачем здесь Код: plaintext 1. кажется понял. Это наверное для того чтобы обнаружить NULLы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 18:55:46 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
хотя не снимается Код: sql 1. 2. 3. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. ведь эквивалентен Код: sql 1. 2. 3. 4. 5. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. однако второй запрос никаких натурал сканов в плане не имеет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 19:24:34 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
один момент я всё же опустил ведь эквивалентен Код: sql 1. 2. 3. 4. 5. 6. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 19:59:14 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
Симонов Денис, в методах доступа этого нет, ибо (а) статья старая и (б) это не новый метод доступа, а использование старых. Просто предикат преобразован в другую форму. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:52:00 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
ТаблоидБудет ли материализация результатов подзапросов, которая вроде как грядёт в скором времени в ФБ-3, распространена также на то, что внутри [not] in( ... ) ? все может быть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2014, 21:53:25 |
|
||
|
NOT IN( select from X), где "X" содержит NULL в первой записи: всегда ли он это учитывает?
|
|||
|---|---|---|---|
|
#18+
dimitr Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Спасибо. Теперь ясно откуда такой план. Да и на вопрос про двойную сортировку это даёт ответ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2014, 09:08:30 |
|
||
|
|

start [/forum/search_topic.php?author=phdoc&author_mode=last_topics&do_search=1]: |
0ms |
get settings: |
8ms |
get forum list: |
15ms |
get settings: |
7ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
316ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 386ms |
| total: | 819ms |

| 0 / 0 |
