powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select * from (select ....) ... оптимизация
7 сообщений из 7, страница 1 из 1
select * from (select ....) ... оптимизация
    #40108770
hlopotun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Всем доброго дня,

разбираю сейчас проблемы с неиндексированными запросами в одном из проектов и столкнулся с запросами вида
select Table.A, Table.B, Table.D from (select * from Table where ....) where .... которые по идее переписываются без проблем как
select Table.A, Table.B, Table.D from Table where ....
Посколку явление это в этом проекте массовое и походу эти запросы генерируются фреймворком автоматически (этот вопрос я пока проясняю) возникает вопрос насколько такие запросы проблематичны. IBExpert при анализе их производительности показывает что всё в порядке и если есть задержки по причине отсутствия индексов при их создании они исчезают. Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
вот пара примеров таких запросов:

Код: sql
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.
select PO_STATUS from (select * from v_55_uebersicht v INNER JOIN (select distinct pro.proid as pid, u.id, u.username, u.isadmin 
from projekte pro LEFT JOIN prouserroles pur ON pro.proid=pur.proid RIGHT JOIN (select username, isadmin, id 
from v_85_zavuserroles where (username = 'SYSOP')) u ON u.ID = pur.userid or u.isadmin = 'T') 
roles ON cast (case when (v.proid is null) or (v.proid = 'min') then '{00000000-0000-0000-0000-000000000000}' 
else v.proid end as varchar (38)) = roles.pid) where (AUFTRID = '{0002152D-FBD7-45FA-9468-DD400F89CC7F}')

Plan
--------------------------------------------------------------------------------
PLAN SORT ((V TK_TECHORDERS INDEX (IDX_TK_TECHORDERS_UPDT)))
PLAN (V TK_TECHOBJECTS INDEX (RDB$FOREIGN25))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN SORT ((V TK_PURCHASEORDERS INDEX (IDX_TK_PURCHASEORDERS_UPDT)))
PLAN MERGE (SORT (SORT (JOIN (JOIN (JOIN (ROLES U V_85_ZAVUSERROLES U INDEX (IDX_ZAVUSER_USERNAME), ROLES U V_85_ZAVUSERROLES RA INDEX (PKUSERROLES)), ROLES U V_85_ZAVUSERROLES RS INDEX (PKUSERROLES)), JOIN (ROLES PRO NATURAL, ROLES PUR INDEX (FK_PROUSERROLES_PRO))))), SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (V A INDEX (RDB$PRIMARY4), V PRO INDEX (RDB$PRIMARY2)), V BL INDEX (RDB$PRIMARY17)), V BEARB INDEX (RDB$PRIMARY17)), V AUFMBEARB INDEX (RDB$PRIMARY17)), V TECHORD INDEX (RDB$PRIMARY22)), V TECHOBJ INDEX (RDB$PRIMARY24)), V SI_A INDEX (RDB$PRIMARY27)), V SI_B INDEX (RDB$PRIMARY27)), V POORD INDEX (RDB$PRIMARY30)), V B INDEX (RDB$PRIMARY4)), V SEN SE ORDER IDX_TK_SERVICEENTRIES_DTAG_ASC INDEX (IDX_TK_SERVICEENTRIES_DTAG_ASC))))

Adapted Plan
--------------------------------------------------------------------------------
PLAN SORT ((V TK_TECHORDERS INDEX (IDX_TK_TECHORDERS_UPDT)))
PLAN (V TK_TECHOBJECTS INDEX (INTEG_86))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN (V TK_SITEINFOS INDEX (IDX_TK_SITEINFOS_TO))
PLAN SORT ((V TK_PURCHASEORDERS INDEX (IDX_TK_PURCHASEORDERS_UPDT)))
PLAN MERGE (SORT (SORT (JOIN (JOIN (JOIN (ROLES U V_85_ZAVUSERROLES U INDEX (IDX_ZAVUSER_USERNAME), ROLES U V_85_ZAVUSERROLES RA INDEX (PKUSERROLES)), ROLES U V_85_ZAVUSERROLES RS INDEX (PKUSERROLES)), JOIN (ROLES PRO NATURAL, ROLES PUR INDEX (FK_PROUSERROLES_PRO))))), SORT (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (JOIN (V A INDEX (INTEG_12), V PRO INDEX (INTEG_6)), V BL INDEX (INTEG_57)), V BEARB INDEX (INTEG_57)), V AUFMBEARB INDEX (INTEG_57)), V TECHORD INDEX (INTEG_62)), V TECHOBJ INDEX (INTEG_64)), V SI_A INDEX (INTEG_67)), V SI_B INDEX (INTEG_67)), V POORD INDEX (INTEG_100)), V B INDEX (INTEG_12)), V SEN SE ORDER IDX_TK_SERVICEENTRIES_DTAG_ASC INDEX (IDX_TK_SERVICEENTRIES_DTAG_ASC))))

------ Performance info ------
Prepare time = 0ms
Execute time = 0ms
Avg fetch time = 0,00 ms
Current memory = 43.570.748
Max memory = 48.881.948
Memory buffers = 2.048
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 2.546

или

select LOGID, MSGID, REFTOMSGID, AUFTRID, DTAGVGID, BUYERTECHORDERID, OBJ_DESCRIPTION, OBJ_TIME, LCH_DATE, LCH_USER from (select * from WSObjLog) where ((DTAGVGID is null)) order by LOGID asc, AUFTRID asc



Plan
--------------------------------------------------------------------------------
PLAN SORT ((WSOBJLOG INDEX (IDX_WSOBJLOG_DTAGVGID)))

------ Performance info ------
Prepare time = 16ms
Execute time = 109ms
Avg fetch time = 7,27 ms
Current memory = 36.841.296
Max memory = 36.849.912
Memory buffers = 2.048
Reads from disk to cache = 15.269
Writes from cache to disk = 0
Fetches from cache = 75.342
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40108774
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hlopotun
Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
Какие именно сомнения ? В чём проблема выполнить два запроса и сравнить время, планы, статистику ?
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40108775
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hlopotun
которые по идее переписываются без проблем как
Совершенно не факт, что от этого они станут оптимальнее.

hlopotun
вот пара примеров таких запросов:
первый запрос, на вой взгляд, написан в трудном для понимания стиле. Лично я бы его переписал на более удобоваримый.

Звездочки - зло независимо от.
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40108781
hlopotun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
hvlad
hlopotun
Но у меня возникают сомнения на тему внутренней оптимизации таких запросов в FB (2.5.8)
Какие именно сомнения ? В чём проблема выполнить два запроса и сравнить время, планы, статистику ?


в тех запросах что найду да, но поскольку фреймворк по видимому некоторые из них генерирует сам то интересен ответ на вопрос - в плане оптимизации, само по себе использование select ... from (select ...) порочно или нет для FB 2.5.8?
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40108782
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hlopotun,

Запрос неудобоваримый для чтения. Его хотя бы отформатировать. Я вот очень часто использую "select ... from select ...". Превратить его в один select порой проблематично, поскольку нужно наложить два условия where, причём второе условие уже по "агрегатам". Можно переписать через CTE.
То что джойн к селекту тоже не криминал. Тоже через CTE можно попробовать.
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40108787
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hlopotun
в плане оптимизации, само по себе использование select ... from (select ...) порочно или нет для FB 2.5.8?
Если речь идёт о проталкивании предикатов во внутренний select, то это должно работать.
Или я не понимаю суть сомнений.
...
Рейтинг: 0 / 0
select * from (select ....) ... оптимизация
    #40109162
hlopotun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
спасибо всем,
развеяли сомнения
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / select * from (select ....) ... оптимизация
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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