Гость
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird 3.0 and plan analyzer / 24 сообщений из 24, страница 1 из 1
09.07.2018, 16:32
    #39671699
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Привет!

Внезапно обнаружил, что последняя версия Firebird 3.0.3.32900 для любого серективного запроса в IBExpert SQL Editor select * from A_TEST показывает в Plan Analyzer как PLAN (ANY_PROC_NAME NATURAL)

Если запустить Firebird 2.5.2.26540, то Plan Analyzer показывает план и его можно анализировать.

База создается из одного и того же SQL файла.
Та же ситуация и при просмотре Plan Analyzer внутри открытой на редактирование процедуры.

IBExpert - последняя версия, но и старые версии ведут себя так же.

Проверял на Windows 10 64-bit, Windows 7 64bit.

Пожалуйста, подскажите кто виноват и что делать.

(Attached FB30-25.PNG)
...
Рейтинг: 0 / 0
09.07.2018, 16:41
    #39671703
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005,

план процедуры - это plan natural
план запроса в процедуре - это план запроса из процедуры.

Раньше (в 2.5) было неправильно, теперь - правильно. Допустим, в процедуре по условию А = 0 выполняется один запрос, а по условию А = 1 - второй запрос. В плане процедуры выводилось оба плана, хотя одновременно они никогда не выполнялись . Что это дает тебе лично? В чем проблема скопировать конкретный запрос в sql editor и посмотреть его план?
...
Рейтинг: 0 / 0
09.07.2018, 16:42
    #39671704
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005,

в 3.0 план при обращении к ХП всегда NATURAL, планы внутренних запросов внутри ХП больше не раскрываются
...
Рейтинг: 0 / 0
09.07.2018, 16:50
    #39671712
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Симонов Денис,

собственно, выборка из процедуры по смыслу эквивалентна select * from table, где у table нет ни одного индекса (а у процедуры их и нет).
В результате действительно получается plan procname natural. И никакие where, order by, group by и прочее сверху к процедуре "вовнутрь" пропихнуть невозможно (в отличие от view).
...
Рейтинг: 0 / 0
09.07.2018, 17:16
    #39671731
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
на самом деле, мотивация была следующая:

1) при джойнах (особенно многоэтажных) с процедурами, их план тупо "встраивался" по месту потока процедуры, делая результат абсолютно кривым синтаксически (включая невозможность адекватного парсинга)

2) при больших процедурах план тупо обрезался, делая любой его анализ бессмысленным

3) что делать для detailed plan - каждый раз встраивать всю портянку в дерево или делать какие-то внешние ссылки или еще что-то

Выкинуть эту псевдофичу к чертовой матери показалось самым очевидным решением :-)
...
Рейтинг: 0 / 0
09.07.2018, 17:17
    #39671732
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
kdv,

Спасибо за разъяснение.

Предыстория: Я заметил, что в Firebird 3.0 выборка одного и того же набора данных из базы размером N происходит в три раза медленнее, чем из базы размером 2N. Удивился и полез смотреть что там с планом. А там теперь ничего нет. И как теперь опримизировать запросы? Поэтому и решил спросить здесь.
...
Рейтинг: 0 / 0
09.07.2018, 17:23
    #39671737
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005,

копировать операторы из ХП подготоваливать их смотреть планы.
...
Рейтинг: 0 / 0
09.07.2018, 17:27
    #39671741
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
09.07.2018 17:23, Симонов Денис пишет:
> копировать операторы из ХП подготоваливать их смотреть планы.

в IBExpert'е есть "отладчик" процедур.
он это умеет.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
09.07.2018, 17:58
    #39671754
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005выборка одного и того же набора данных из базы размером N происходит в три раза медленнее, чем из базы размером 2NНичего не перепутал ? :)

PS всё равно - не верю, без чисел
...
Рейтинг: 0 / 0
09.07.2018, 18:01
    #39671759
IBExpert
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005И как теперь опримизировать запросы?

В редакторе процедур на закладке "Операции / Использование индексов" все запросы процедуры списком, вместе с планами.
...
Рейтинг: 0 / 0
09.07.2018, 19:32
    #39671789
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
hvlad,

авторНичего не перепутал ? :) PS всё равно - не верю, без чисел

Нет. Обе базы аккуратно сохранены для исследования.

База размером N:

Prepare time = 0ms
Execute time = 1s 466ms
Avg fetch time = 91.63 ms
Current memory = 20,737,680
Max memory = 20,856,264
Memory buffers = 2,048
Reads from disk to cache = 913
Writes from cache to disk = 2
Fetches from cache = 2,457,747

База размером 2N:

------ Performance info ------
Prepare time = 0ms
Execute time = 32ms
Avg fetch time = 2.00 ms
Current memory = 21,442,552
Max memory = 21,689,392
Memory buffers = 2,048
Reads from disk to cache = 615
Writes from cache to disk = 0
Fetches from cache = 18,644
...
Рейтинг: 0 / 0
09.07.2018, 19:33
    #39671791
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Спасибо всем за подсказки по IBExpert.

Попытаюсь через отладку понять откуда появились тормоза.

"Треугольник будет выпит."
...
Рейтинг: 0 / 0
09.07.2018, 19:48
    #39671799
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB20051
Reads from disk to cache = 913
Writes from cache to disk = 2
Fetches from cache = 2,457,747

2
Reads from disk to cache = 615
Writes from cache to disk = 0
Fetches from cache = 18,644

разницу невооруженным глазом видно. Причины
- где-то или не хватает индекса, или не пересчитана селективность индексов.
В общем, надо смотреть планы запросов.
...
Рейтинг: 0 / 0
09.07.2018, 20:38
    #39671810
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005авторНичего не перепутал ? :) PS всё равно - не верю, без чисел

НетНу, тогда всё просто - чем больше БД, тем быстрее запросы в ней
Поздравляю

PS 1466/32 никак не 3
PPS планы сравнивай
...
Рейтинг: 0 / 0
10.07.2018, 20:25
    #39672259
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Продолжение истории.

Используя ваши подсказки, сравнил планы, явно прописал хороший план к SELECT и получил опять быстрое извлечение данных.

После этого достал сохраненную базу размером N (медленный план), посмотрел информацию о нем на закладке Operations / Index Using (спасибо user IBExpert за подсказку),
добавил второй набор данных (получил базу размером 2N), отключился от сервера, открыл базу в IBExpert, перешел на закладку Operations / Index Using и увидел совершенно другой план. (План, который позволяет быстро выбирать данные.)
(В пустой только что созданной базе план тоже изначально плохой.)

Получается, что сервер способен со временм изменять планы, основываясь на количестве данных/других характеристиках базы ("учится")?

Но в таком случае не сможет ли он случайно ухудшить изначально хороший план вызова запроса?

Что скажут разработчики Firebird?
...
Рейтинг: 0 / 0
10.07.2018, 20:32
    #39672261
YuRock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005Но в таком случае не сможет ли он случайно ухудшить изначально хороший план вызова запроса?Если статистика индексов полетела - может.
Пересчитай статистику всех индексов (в ибэксперт есть recompute all на вкладке индексы) для нужных таблиц, убери свои планы, и должно стать оптимально.
...
Рейтинг: 0 / 0
10.07.2018, 20:42
    #39672263
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005,

https://www. youtube.com/watch?v=0KITHwMNDtw

добавлю, что статистика по индексам не пересобирается сама. можно автоматизировать старт set statistics... на 1-2 раза в неделю, например.
Но при анализе планов и прочего селективность надо пересчитать.
...
Рейтинг: 0 / 0
11.07.2018, 04:03
    #39672332
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
FB2005Получается, что сервер способен со временм изменять планы, основываясь на количестве данных/других характеристиках базы ("учится")?

Но в таком случае не сможет ли он случайно ухудшить изначально хороший план вызова запроса?

Что скажут разработчики Firebird?

Не разработчик, но такое периодически бывает, приходится запросы подкручивать.
Планы не задаю, но очень широко использую left join.
...
Рейтинг: 0 / 0
11.07.2018, 11:02
    #39672424
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
11.07.2018 4:03, fraks пишет:
> Планы не задаю, но очень широко использую left join.

весьма сомнительный рецепт
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.07.2018, 11:57
    #39672461
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Мимопроходящий11.07.2018 4:03, fraks пишет:
> Планы не задаю, но очень широко использую left join.

весьма сомнительный рецепт


Если использовать INNER только там где нужен именно INNER - а в остальных случаях использовать OUTER и он там допустим - вполне нормальный рецепт.
...
Рейтинг: 0 / 0
11.07.2018, 12:23
    #39672480
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
left нужен только там, где нужен именно left.
left меняет не только порядок соединения но и "механизм" получения результата.

ps: я сейчас стараюсь порядок соединения при помощи +0 рулить.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
11.07.2018, 12:40
    #39672487
fraks
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Мимопроходящийleft нужен только там, где нужен именно left.
left меняет не только порядок соединения но и "механизм" получения результата.

Именно потому что left не своевольничает в применении планов - его и применяю.
Может быть у меня будет не самый лучший план для всех случаев, но он будет по крайней мере стабильным.
В большинстве случаев соединяется мастер-деталь, причем мастер эффективно ограничивается условиями.

Мимопроходящийps: я сейчас стараюсь порядок соединения при помощи +0 рулить.


+0 не рулит соединениями, он позволяет исключить использование неэффективного в данном запросе индекса.
И да, это изменяет или может изменить план, но это уже следствие.

Тоже иногда применяю эту фишку.
...
Рейтинг: 0 / 0
11.07.2018, 13:16
    #39672512
WildSery
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
fraks,

Зато +0 может соединить отличным от nested loops способом.
...
Рейтинг: 0 / 0
11.07.2018, 19:02
    #39672721
FB2005
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Firebird 3.0 and plan analyzer
Вызов SET STATISTICS помог. Большое спасибо.

Немного странно, что изначально план формировался как NATURAL, а после появления данных и обновления selectivity вдруг обнаружил индексы и перестроился без NATURAL.

Надеюсь, API позволяет получить текущий используемый план для SELECT, чтобы при необходимости записать его в лог и посмотреть план, не имея доступа к самой базе.
...
Рейтинг: 0 / 0
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Firebird 3.0 and plan analyzer / 24 сообщений из 24, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]