|
По планам
|
|||
---|---|---|---|
#18+
Приветствую знатоков и разработчиков! Занимаюсь вопросом перехода с Firebird 1.5 на WI-V3.0.7.33374 Firebird 3.0. Есть следующая таблица Код: 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.
Пытаюсь делать запрос Код: plsql 1. 2.
В WI-V1.5.6.5026 Firebird 1.5 получаю PLAN (B INDEX (TBL_IDX_FLD)) PLAN (A NATURAL) ------ Performance info ------ Prepare time = 16ms Execute time = 13s 625ms Avg fetch time = 13 625,00 ms Current memory = 33 030 024 Max memory = 39 871 552 Memory buffers = 3 000 Reads from disk to cache = 779 Writes from cache to disk = 0 Fetches from cache = 2 849 118 В WI-V3.0.7.33374 Firebird 3.0 получаю: PLAN (B INDEX (TBL_IDX_FLD, TBL_IDX_ID)) PLAN (A NATURAL) ------ Performance info ------ Prepare time = 31ms Execute time = 39s 204ms Avg fetch time = 39 204,00 ms Current memory = 29 546 384 Max memory = 31 280 352 Memory buffers = 3 000 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 2 156 038 Не очень понятно, зачем тут используется индекс TBL_IDX_ID по полю, у которого всего 5 разных значений среди таблицы в 100 тыс записей. Такой вариант работает в 45 раз быстрее: Код: plsql 1. 2.
PLAN (B INDEX (TBL_IDX_FLD)) PLAN (A NATURAL) ------ Performance info ------ Prepare time = 32ms Execute time = 953ms Avg fetch time = 953,00 ms Current memory = 29 546 928 Max memory = 31 280 352 Memory buffers = 3 000 Reads from disk to cache = 0 Writes from cache to disk = 0 Fetches from cache = 1 590 140 45 раз - это существенная разница. Есть какой-нибудь полу-автоматический способ решения подобных проблем? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 16:45 |
|
По планам
|
|||
---|---|---|---|
#18+
27.10.2020 16:45, ggreggory пишет: > Не очень понятно, зачем тут используется индекс TBL_IDX_ID по полю, у которого всего 5 разных значений среди таблицы в 100 тыс записей. не очень понятно, нахер ты его создал... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 16:47 |
|
По планам
|
|||
---|---|---|---|
#18+
Мимопроходящий 27.10.2020 16:45, ggreggory пишет: > Не очень понятно, зачем тут используется индекс TBL_IDX_ID по полю, у которого всего 5 разных значений среди таблицы в 100 тыс записей. не очень понятно, нахер ты его создал... Это пример, демонстрирующий суть проблемы. В реальности это индекс внешнего ключа с одной таблицы на другую, кол-во записей в которых и их соотношение нельзя проконтролировать. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 17:06 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggoryВ WI-V1.5.6.5026 Firebird 1.5 получаю Execute time = 13s 625ms Reads from disk to cache = 779 Fetches from cache = 2 849 118 В WI-V3.0.7.33374 Firebird 3.0 получаю: Execute time = 39s 204ms Reads from disk to cache = 0 Fetches from cache = 2 156 038 Я один думаю, что где-то в этих яблоках затесались апельсины?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 17:21 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory, статистику обновлял? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 17:21 |
|
По планам
|
|||
---|---|---|---|
#18+
Симонов Денис ggreggory, статистику обновлял? Посмотрите повнимательнее, это есть в примере. Dimitry Sibiryakov Я один думаю, что где-то в этих яблоках затесались апельсины?.. 1.5 Classic, 3.0 Super, кэш тоже разный. Но не думаю, что это повлияет на планы. Или нет? В любом случае вы можете запустить это пример у себя на своей версии сервера с вашими параметрами. Если у вас другие данные получатся - напишите! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 17:34 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory, архитектура на план не влияет никак. Оптимизатор один. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 18:10 |
|
По планам
|
|||
---|---|---|---|
#18+
27.10.2020 18:10, kdv пишет: > архитектура на план не влияет никак. Оптимизатор один. он статистику пытается пересчитывать "изнутри" процедуры. а тут как раз есть варианты. (недавно обсуждали) Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 18:15 |
|
По планам
|
|||
---|---|---|---|
#18+
Мимопроходящий 27.10.2020 18:10, kdv пишет: > архитектура на план не влияет никак. Оптимизатор один. он статистику пытается пересчитывать "изнутри" процедуры. а тут как раз есть варианты. (недавно обсуждали) Вот что у меня выдает Код: plsql 1.
WI-V3.0.7.33374 Firebird 3.0 TBL_IDX_FLD 0.0002144082391168922 TBL_IDX_ID 0.1666666716337204 WI-V1.5.6.5026 Firebird 1.5 TBL_IDX_FLD 0.0002144082391168922 TBL_IDX_ID 0.1666666716337204 Несколько раз туда-сюда пересчитывал. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 18:26 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggoryMemory buffers = 3 000 Memory buffers = 3 000 1.5 Classic, 3.0 Super, кэш тоже разный. Кто-то или врёт или добросовестно заблуждается. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 18:34 |
|
По планам
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov ggreggoryMemory buffers = 3 000 Memory buffers = 3 000 1.5 Classic, 3.0 Super, кэш тоже разный. Кто-то или врёт или добросовестно заблуждается. Что же вы все подвох везде ищете. Я запускал тест на первых двух попавшихся базах данных. Если вы не верите мне, запустите его у себя, предлагал же! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 18:45 |
|
По планам
|
|||
---|---|---|---|
#18+
Вряд ли это имеет отношение к планам, но вот статистика: WI-V3.0.7.33374 Firebird 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. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43.
Код: 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 19:01 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggoryЕсли вы не верите мне, запустите его у себя, предлагал же! Я верю. Но никак не могу понять смысла этого топика и что именно ты хочешь добиться. http://www.ibase.ru/dataaccesspaths/ ты уже изучил? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 19:14 |
|
По планам
|
|||
---|---|---|---|
#18+
Я верю. Но никак не могу понять смысла этого топика и что именно ты хочешь добиться. Я в надежде на какой-нибудь спасительный патч, который всё исправит. Ну типа update rdb$indices set rdb$statistics = 1 where rdb$statistics > 0.1 http://www.ibase.ru/dataaccesspaths/ ты уже изучил? Читал давно, но подробно не изучал. Поизучаю подробнее, возможно появятся мысли. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 20:04 |
|
По планам
|
|||
---|---|---|---|
#18+
если вкратце, то оптимизатор в 1.5 и 2.х/3.х/4.х работает зело по-разному. В 1.5 он видит отличие в селективности более порядка и тупо выкидывает TBL_IDX_ID из рассмотрения. В более новых версиях он считает стоимость выборки как с одним индексом, так и с обоими. И в данном случае решает, что оба будут выгоднее. И для отдельного подзапроса это возможно и верно. А вот то, что он коррелированный и что условие b.id = 0 возвращает один и тот же битмап на каждую запись внешнего запроса - это не учитывается. Такова селяви. Пока что придется как-то с этим жить :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 20:04 |
|
По планам
|
|||
---|---|---|---|
#18+
dimitr В более новых версиях он считает стоимость выборки как с одним индексом, так и с обоими. И в данном случае решает, что оба будут выгоднее. Возможно, глупость напишу, но при сравнении селективности учитывается, что для двух индексов надо будет делать пересечение битовых карт, а для одного нет, и это тоже сколько-то стоит? По формуле из статьи (bestSel + (((worstSel - bestSel) / (1 - bestSel)) * bestSel)) / 2 в моём примере получается ( 0.0002144082391168922 + ((( 0.1666666716337204 - 0.0002144082391168922) / (1 - 0.0002144082391168922)) * 0.0002144082391168922)) / 2 = 0.000125 т.е. разница 0.000125 и 0.000214 не ахти какая большая, но с двумя индексами на порядок медленнее. Просто уж очень много всяких FOREIGN KEYS со ссылкой на маленькие таблички, которые портят планы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 20:31 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory Просто уж очень много всяких FOREIGN KEYS со ссылкой на маленькие таблички, которые портят планы. И делетов-апдейтов ID в этих маленьких табличках не делается никогда в жизни. Ну и на пуркуа тогда эти FK? Триггера на инсертах в большие таблицы со ссылками справятся с проверкой наличия записей в маленьких на ура и не будет гемора оптимизатору. В 1.5 они (эти FK) ему тоже крышу сносят время от времени. Не надо быть догматиком, надо чуйствовать свою задачу. Этто я не с высокой колокольни, тоже лет 10 назад изводил грехи молодости. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 20:41 |
|
По планам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Триггера на инсертах в большие таблицы со ссылками справятся с проверкой наличия записей в маленьких на ура и не будет гемора оптимизатору. Так и делаем, но там, где точно ясно - таблица всегда была и будет маленькой. Триггерами или вообще контроль на уровне прикладного ПО. Вопросы возникают в случае, если: ggreggory В реальности это индекс внешнего ключа с одной таблицы на другую, кол-во записей в которых и их соотношение нельзя проконтролировать . ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 21:01 |
|
По планам
|
|||
---|---|---|---|
#18+
Старый плюшевый мишка Триггера на инсертах в большие таблицы со ссылками справятся с проверкой наличия записей в маленьких на ура и не будет гемора оптимизатору. Да, наверное это единственный вариант в данной ситуации! Он хотя бы позволяет управлять индексом (создавать где надо и отключать где надо). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 21:18 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory Старый плюшевый мишка Триггера на инсертах в большие таблицы со ссылками справятся с проверкой наличия записей в маленьких на ура и не будет гемора оптимизатору. Да, наверное это единственный вариант в данной ситуации! Он хотя бы позволяет управлять индексом (создавать где надо и отключать где надо). В запросе-то отключить существующий индекс через+0 не проблема. Но вот на действительно больших таблицах начинают тормозить инсёрты перестройкой FK, а на ресторе просто мрак на их создании. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.10.2020, 21:22 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory Симонов Денис ggreggory, статистику обновлял? Посмотрите повнимательнее, это есть в примере. Вот теперь посмотрел внимательно. Так у тебя в этом индексе 999994 значений равно 0 из 1000000. У оптимизатора нет информации о распределении ключей (гистограмм), есть только селективность индекса. Селективность предполагает что ваши значения в ключах распределены боле менее равномерно. Он достаточно неплохая для этого индекса 0.1666666716337204 А вот если бы были гистограммы, то он бы обнаружил что реальная селективность для значения 0 плохая. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2020, 09:28 |
|
По планам
|
|||
---|---|---|---|
#18+
Симонов Денис Так у тебя в этом индексе 999994 значений равно 0 из 1000000. Запрос Код: plsql 1.
выдает Код: plaintext 1. 2. 3. 4. 5. 6.
... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2020, 09:32 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory, походу я ещё сплю, пора кофе пить (( ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2020, 09:43 |
|
По планам
|
|||
---|---|---|---|
#18+
ggreggory Старый плюшевый мишка Триггера на инсертах в большие таблицы со ссылками справятся с проверкой наличия записей в маленьких на ура и не будет гемора оптимизатору. Так и делаем, но там, где точно ясно - таблица всегда была и будет маленькой. Триггерами или вообще контроль на уровне прикладного ПО. Вопросы возникают в случае, если: ggreggory В реальности это индекс внешнего ключа с одной таблицы на другую, кол-во записей в которых и их соотношение нельзя проконтролировать . когда-то заявлялось в фичах, что создание constraint не обязательно будет сопровождаться созданием индекса. это до альфы тройки не смогли найти внетранзакционного механизма контроля. обосновали, привели примеры нерешаемых косяков. принял как данность, живу с никчемными индексами. таблицы, имеющие малое количество записей, и не подлежащие изменениям пользователями (системные справочники - пол, тип алгоритма, тип проводки и пр.) превратил в int домены. и сделал справочник - имя_домена, значение, текст, примечание. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.10.2020, 11:13 |
|
|
start [/forum/topic.php?fid=40&fpage=11&tid=1560211]: |
0ms |
get settings: |
12ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
74ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
2ms |
others: | 239ms |
total: | 434ms |
0 / 0 |