|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Merge (INDEX + INDEX) = 10 фетчей на запись. Т.е. можно считать, что для ORDER INDEX требуется 3 фетча на запись (1 btree page, 1 pointer page, 1 data page). Таким образом MERGE(ORDER INDEX, ORDER INDEX) потребует 6 фетчей на запись (если нет промахов, т.е. соединение 1 к 1). Точнее 3N + 3M фетчей при наличии N и M записей в таблицах. Для NATURAL + INDEX потребуется 2N + 5N фетчей. Однако это далеко не полный анализ стоимости, т.к. он совсем не учитывает IO. Добавлю также, что в fb3 кол-во фетчей PP сокращено, и для NATURAL оно стремится к кол-ву самих PP, которых сильно меньше чем DP. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 21:33 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov ggreggoryно могу написать процедуры, эмулирующие эту ситуацию: Походу, не смог. У тебя join внутренний, а в топике всё время речь про внешний. Ну хорошо, select count(*) from (select tbl.text, join_tbl.text as join_text from tbl left join join_tbl on tbl.id = join_tbl.id), без разницы, таблицы полностью идентичны, что left, что right, что inner, всё одно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 21:34 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
ggreggory Код: sql 1. 2. 3. 4.
ggreggory Код: sql 1.
Где такое бывает ? Где вообще бывает связь PK:FK 1:1 ? Но, ок, предположим, что у нас 1:1, но FK заполненный строго по возрастанию - это уже слишком. ggreggory select count(*) from test_index = 26 секунд ... Среднее время выполнения select count(*) from (select tbl.text, join_tbl.text as join_text from tbl join join_tbl on tbl.id = join_tbl.id) у меня 10 секунд. Разница в 2.6 раза не смущает ? ggreggory В обоих случаях всё в памяти, Reads from disk to cache = 0 ggreggory Таким образом если бы этот запрос делался не по индексу, а объединением, т.е. быстрее на 7 секунд ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 21:41 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
ggreggory Вопрос в том, почему Firebird не хочет использовать merge join в этом случае Попробуй этот запрос в MSSQL не для кластерного и не для покрывающего индекса. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 21:44 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
ggreggoryбез разницы Ты не врубился: у тебя в процедурах идёт исключительно inner join для примитивного соединения 1:1 по первичному ключу. Вот когда ты их напишешь так, чтобы они выдавали правильный результат для M:N, тогда их и можно будет сравнивать с запросом. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 21:51 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
hvlad А чего не VARCHAR(100500) ? Зачем скромничать ? Ну, это как-бы эмулирует "другие поля таблицы", не один же ключ в ней должен быть. hvlad ...но FK заполненный строго по возрастанию - это уже слишком. Ок, согласен, пример переделал (там еще перепутаны были исходная и присоединяемая таблица): Код: plsql 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. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82.
hvlad Разница в 2.6 раза не смущает ? Так там PSQL, а тут DML, конечно то же самое процедурой будет медленнее, я про это и написал выше. hvlad ggreggory В обоих случаях всё в памяти, Reads from disk to cache = 0 Кэш я увеличил для иллюстрации корректности сравнения цифр, чтение с диска всегда сильно портит результат. hvlad С какой стати эта разница PSQL запросов переносится один-в-один на гипотетический "запрос с объединеним" ? Скажем так, это оценка. У меня нет какого-либо другого инструмента, чтобы проверить, "чтобы было если бы Firebird мог так делать". Планы и результаты: select count(*) from test_index: ------ Performance info ------ Prepare time = 31ms Execute time = 15s 750ms Avg fetch time = 15 750,00 ms Current memory = 1 747 296 368 Max memory = 2 758 462 928 Memory buffers = 102 400 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 7 018 615 select count(*) from test_merge ------ Performance info ------ Prepare time = 15ms Execute time = 12s 63ms Avg fetch time = 12 063,00 ms Current memory = 1 747 296 368 Max memory = 2 758 462 928 Memory buffers = 102 400 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 5 018 617 select count(*) from (select tbl.text, join_tbl.text as join_text from tbl left join join_tbl on tbl.id = join_tbl.id) Plan -------------------------------------------------------------------------------- PLAN JOIN (TBL NATURAL, JOIN_TBL INDEX (PK_TBL)) ------ Performance info ------ Prepare time = 31ms Execute time = 5s 406ms Avg fetch time = 5 406,00 ms Current memory = 1 747 310 800 Max memory = 2 758 462 928 Memory buffers = 102 400 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 6 078 060 Разница уменьшилась, теперь 3 секунды. Вы можете попробовать у себя запустить этот тест. Возможно, у вас будут другие соотношения. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 23:32 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
hvlad ggreggory Вопрос в том, почему Firebird не хочет использовать merge join в этом случае А если все страницы данных будут в кэше? Я конечно понимаю, что есть БД, которые ну никак в ОЗУ не впихиваются, но большинство же вполне влезает. Dimitry Sibiryakov Ты не врубился: у тебя в процедурах идёт исключительно inner join для примитивного соединения 1:1 по первичному ключу. Вот когда ты их напишешь так, чтобы они выдавали правильный результат для M:N, тогда их и можно будет сравнивать с запросом. По TEST_INDEX не согласен, там четко пробегается по всем записям первой таблицы и ищется по PK запись в связанной таблице. По TEST_MERGE - согласен, написал на скорую руку, но для этого конкретного примера она выдает корректный результат. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.11.2021, 23:38 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
ggreggoryПо TEST_INDEX не согласен, там четко пробегается по всем записям первой таблицы и ищется по PK запись в связанной таблице. Добавь в JOIN_TBL только каждую вторую запись из TBL, но дважды. "Вот тогда-то мы и повеселимся..." (с) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2021, 00:47 |
|
Почему FB 2.5.8 не использует FK индекс в запросе
|
|||
---|---|---|---|
#18+
И вообще не заморачивайся пока с миллионами и производительностью. Для начала просто заставь свои процедуры выдавать корректный результат на простых данных: https://dbfiddle.uk/?rdbms=firebird_3.0&fiddle=580347a8e7361360ec67fda82e3fa78c Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
08.11.2021, 00:59 |
|
|
start [/forum/topic.php?fid=40&msg=40109879&tid=1559895]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
148ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 259ms |
total: | 505ms |
0 / 0 |