ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение планировщика в FB3.
8 сообщений из 8, страница 1 из 1
Странное поведение планировщика в FB3.
    #39647644
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
Столкнулся с непонятным моментом. Привожу тестовый запрос.
Код: sql
1.
2.
3.
4.
5.
select k.*, d.sod
from defect d
     inner join kts k on k.id_kts=d.id_kts
     left outer join sotr s on s.id_sotr=d.id_kontr
where k.id_tip=2249


Результат:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
План
PLAN JOIN (JOIN (K INDEX (FK_KTS_RELATIONS_SPRAV), D INDEX (DEFECT_IDX5)), S INDEX (PK_SOTR))

------ Информация о производительности ------
Время подготовки запроса = 16ms
Время выполнения запроса = 1s 794ms
Среднее время на получение одной записи = 0,01 ms
Current memory = 58 978 416
Max memory = 148 796 256
Memory buffers = 12 000
Reads from disk to cache = 13 814
Writes from cache to disk = 1
Чтений из кэша = 1 063 774


Всё вполне устраивает.
Но, если строчку переставить вот так:
Код: sql
1.
2.
3.
4.
5.
select k.*, d.sod
from defect d
     left outer join sotr s on s.id_sotr=d.id_kontr
     inner join kts k on k.id_kts=d.id_kts
where k.id_tip=2249


То результат:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
План
PLAN JOIN (JOIN (D NATURAL, S INDEX (PK_SOTR)), K INDEX (PK_KTS))

------ Информация о производительности ------
Время подготовки запроса = 0ms
Время выполнения запроса = 1s 934ms
Среднее время на получение одной записи = 0,02 ms
Current memory = 58 849 864
Max memory = 148 796 256
Memory buffers = 12 000
Reads from disk to cache = 13 899
Writes from cache to disk = 1
Чтений из кэша = 1 210 186


Натурал по таблице defect совсем не нравится. Такое поведение планировщика фича? Есть ли описание его работы? Подозреваю, что у нас много запросов такого плана и их надо переделывать.
...
Рейтинг: 0 / 0
21.05.2018, 16:09
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647660
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
баян. Сначала собери вместе все inner-джойны, потом дописывай к ним outer-джойны. Так не будет проблем.
...
Рейтинг: 0 / 0
21.05.2018, 16:31
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647665
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
KreatorXXI,

1. не пиши outer и inner, это лишнее, left/right join не могут быть inner, они только outer
2. left/right join выполняются последовательно, слева направо. Только в случае inner оптимизатор может "перемешать" таблицы в более лучшем порядке.
3. когда пишешь a left join b left join c, старайся, чтобы в левых частях были таблицы поменьше
4. a left join b эквивалентно b right join b, и наоборот. Впрочем, right join сервер внутри переворачивает в left join.
5. смотри видео про оптимизатор и читай http://www.ibase.ru/dataaccesspaths/
6. и т.д.
...
Рейтинг: 0 / 0
21.05.2018, 16:49
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647671
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
KreatorXXI,

кстати, планы хоть и разные, но вышло почти параллельно (по скорости, чтениям и фетчам). Дальше разница будет в зависимости от того, как будет увеличиваться количество данных и в каких таблицах.

А вот индекс для "where k.id_tip=2249" в обоих случаях или не взялся, или его нет.
...
Рейтинг: 0 / 0
21.05.2018, 16:57
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647692
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
KreatorXXI
Участник
dimitrбаян. Сначала собери вместе все inner-джойны, потом дописывай к ним outer-джойны. Так не будет проблем.
Вот так понял. А где-нибудь это описано? Или всё-таки фича ФБ? Реально в запросе не два джойна.
kdv, для поля k.id_tip индекс FK_KTS_RELATIONS_SPRAV, здесь всё хорошо. А почему по скорости примерно одинаково? Просто отключил фильтры по таблице kts, для примера. На самом деле и заметил лишь из-за того, что при накладывании ещё фильтров на таблицу kts ничего не менялось.
...
Рейтинг: 0 / 0
21.05.2018, 17:31
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647701
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
KreatorXXI,
http://tracker.firebirdsql.org/browse/CORE-1239
и ещё пару тикетов было
...
Рейтинг: 0 / 0
21.05.2018, 17:42
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647718
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
KreatorXXIА почему по скорости примерно одинаково?

патамушта почти одинаково:

"Время выполнения запроса = 1s 794ms
Reads from disk to cache = 13 814
Чтений из кэша = 1 063 774

Время выполнения запроса = 1s 934ms
Reads from disk to cache = 13 899
Чтений из кэша = 1 210 186"
...
Рейтинг: 0 / 0
21.05.2018, 18:49
| Ответить | Цитировать | Написать  
Странное поведение планировщика в FB3.
    #39647742
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
KreatorXXI А почему по скорости примерно одинаково?

просто повезло с распределением данных
...
Рейтинг: 0 / 0
21.05.2018, 19:43
| Ответить | Цитировать | Написать  
8 сообщений из 8, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Странное поведение планировщика в FB3.
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39647742&tid=1561097]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 130ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 43ms
get tp. blocked users:
 1ms
others: 12ms
total:  229ms
созд. / загр.: 229ms
x
x
Закрыть


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