Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему? / 25 сообщений из 44, страница 1 из 2
  1  все
17.07.2019, 19:28
    #39838449
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Просветите, почему запрос

Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email from VW_NOLICENSE_VK NL
join address A
on NL.address_id = A.address_id (+)



Выполняется минимум в 2 раза дольше чем

Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email from VW_NOLICENSE_VK NL
join address A
on NL.address_id = A.address_id



Результат запроса на моих данных один и тот же.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 19:30
    #39838450
-2-
-2-
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor Cookin,

explain plan
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:07
    #39838456
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
-2-,

Когда плюс, то индекс ACCESS не используется а идёт
TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 218 Bytes: 4,972,716 Cardinality: 101,484

Недоумеваю, почему
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:08
    #39838457
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
index of ADDRESS table, not ACCESS
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:14
    #39838461
feagor
feagor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor Cookin,

Вы решили использовать ANSI синтаксис совместно внутренним оракловым?
Да вы знаете толк в извращениях.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:30
    #39838469
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
feagor,

Предложения есть?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:34
    #39838470
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
LEFT JOIN?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.07.2019, 20:37
    #39838472
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id



Так те же яйца, тот же план с TABLE ACCESS FULL
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.07.2019, 00:06
    #39838524
Изя Кацман
Изя Кацман
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor Cookin
Код: sql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id



Так те же яйца, тот же план с TABLE ACCESS FULLИ чё?
Оптимизёр выбрал такой план.
Ты возражаешь?

P.S. Яйца спрячь. Зри в корень! :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.07.2019, 20:23
    #39838938
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Изя КацманОптимизёр выбрал такой план.
Он не оптимален
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.07.2019, 20:55
    #39838943
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor CookinИзя КацманОптимизёр выбрал такой план.
Он не оптималенпотому что запрос (и девелопер?) "не оптимален"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
18.07.2019, 23:13
    #39838977
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Вот план с простым JOIN, быстрый:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
Plan
SELECT STATEMENT  ALL_ROWSCost: 534  Bytes: 58,580  Cardinality: 116  									
	14 HASH JOIN  Cost: 534  Bytes: 58,580  Cardinality: 116  								
		12 NESTED LOOPS  Cost: 534  Bytes: 58,580  Cardinality: 116  							
			10 NESTED LOOPS  Cost: 534  Bytes: 58,580  Cardinality: 116  						
				8 STATISTICS COLLECTOR  					
					7 VIEW VIEW SYS.VW_FOJ_0 Cost: 418  Bytes: 52,896  Cardinality: 116  				
						6 FILTER  			
							5 HASH JOIN OUTER  Cost: 418  Bytes: 11,252  Cardinality: 116  		
								2 JOIN FILTER CREATE SYS.:BF0000 Cost: 128  Bytes: 1,007,373  Cardinality: 11,579  	
									1 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT Cost: 128  Bytes: 1,007,373  Cardinality: 11,579  
								4 JOIN FILTER USE SYS.:BF0000 Cost: 290  Bytes: 1,773,880  Cardinality: 177,388  	
									3 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT_LICENSE Cost: 290  Bytes: 1,773,880  Cardinality: 177,388  
				9 INDEX UNIQUE SCAN INDEX (UNIQUE) MDHE.PK_ADDRESS Cost: 0  Cardinality: 1  					
			11 TABLE ACCESS BY INDEX ROWID TABLE MDHE.ADDRESS Cost: 1  Bytes: 49  Cardinality: 1  						
		13 TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 1  Bytes: 49  Cardinality: 1



Вот план с LEFT JOIN, медленный:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
Plan
SELECT STATEMENT  ALL_ROWSCost: 3,890  Bytes: 90,027,865  Cardinality: 178,273  				
	6 HASH JOIN RIGHT OUTER  Cost: 3,890  Bytes: 90,027,865  Cardinality: 178,273  			
		1 TABLE ACCESS STORAGE FULL TABLE MDHE.ADDRESS Cost: 218  Bytes: 4,972,716  Cardinality: 101,484  		
		5 VIEW VIEW SYS.VW_FOJ_0 Cost: 418  Bytes: 81,292,488  Cardinality: 178,273  		
			4 HASH JOIN FULL OUTER  Cost: 418  Bytes: 17,292,481  Cardinality: 178,273  	
				2 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT Cost: 128  Bytes: 2,440,959  Cardinality: 28,057  
				3 TABLE ACCESS STORAGE FULL TABLE MDHE.ESTABLISHMENT_LICENSE Cost: 290  Bytes: 1,773,880  Cardinality: 177,388



Удивительно, но VW_NOLICENSE_VK не использует ни тот ни другой запрос, только если FULL. Да, и времени на FULL - столько же что и на LEFT, даром что 100 000 записей, а не 100.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2019, 17:39
    #39840092
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Up
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2019, 18:12
    #39840115
feagor
feagor
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor Cookin,

я не вижу в твоём запросе предикатов каких-либо кроме связки таблицы с представлением.
Если нет предикатов, значит читать надо всё, так почему бы тогда не использовать table access full?
покажите код представления
Victor Cookin даром что 100 000 записей, а не 100
что это за ограничение, почему до этого про них ничего не говорили? где они в коде?
предоставьте пожалуйста план в читаемом формате например
выполнив
Код: plsql
1.
2.
explain plan for select бла-бла-бла;
select dbms_xplan.display_plan from dual
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
22.07.2019, 23:12
    #39840255
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
feagor,

Медленный запрос /94 rows 500 ms/

Код: plsql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
left join address A
on NL.address_id = A.address_id


Код: css
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                  | Rows   | Bytes    | Cost | Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT               |                       | 178273 | 90027865 | 3890 | 00:00:01 |
| * 1 |   HASH JOIN RIGHT OUTER        |                       | 178273 | 90027865 | 3890 | 00:00:01 |
|   2 |    TABLE ACCESS STORAGE FULL   | ADDRESS               | 101484 |  4972716 |  218 | 00:00:01 |
| * 3 |    VIEW                        | VW_FOJ_0              | 178273 | 81292488 |  418 | 00:00:01 |
| * 4 |     HASH JOIN FULL OUTER       |                       | 178273 | 17292481 |  418 | 00:00:01 |
|   5 |      TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  28057 |  2440959 |  128 | 00:00:01 |
|   6 |      TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 |  1773880 |  290 | 00:00:01 |
------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 1 - access("ADDRESS_ID"="A"."ADDRESS_ID"(+))
* 3 - filter("ESTABLISHMENT_LICENSE_ID" IS NULL AND "E"."EST_CLOSED" IS NULL)
* 4 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID")



Быстрый запрос /94 rows 150 ms/

Код: plsql
1.
2.
3.
4.
select Establishment_id, opening_date, name, nl.phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
attn, (Street1 || ' ' || Street2) Street, city, state_code state, zip_code zip, a.email, inspector_id from VW_NOLICENSE_VK NL 
join address A
on NL.address_id = A.address_id



Код: css
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.
 Plan Hash Value  : 4025364740 

---------------------------------------------------------------------------------------------------------
| Id   | Operation                         | Name                  | Rows   | Bytes   | Cost | Time     |
---------------------------------------------------------------------------------------------------------
|    0 | SELECT STATEMENT                  |                       |    116 |   58580 |  534 | 00:00:01 |
|    1 |   NESTED LOOPS                    |                       |    116 |   58580 |  534 | 00:00:01 |
|    2 |    NESTED LOOPS                   |                       |    116 |   58580 |  534 | 00:00:01 |
|    3 |     VIEW                          | VW_FOJ_0              |    116 |   52896 |  418 | 00:00:01 |
|  * 4 |      FILTER                       |                       |        |         |      |          |
|  * 5 |       HASH JOIN OUTER             |                       |    116 |   11252 |  418 | 00:00:01 |
|    6 |        JOIN FILTER CREATE         | :BF0000               |  11579 | 1007373 |  128 | 00:00:01 |
|  * 7 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  11579 | 1007373 |  128 | 00:00:01 |
|    8 |        JOIN FILTER USE            | :BF0000               | 177388 | 1773880 |  290 | 00:00:01 |
|  * 9 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 | 1773880 |  290 | 00:00:01 |
| * 10 |     INDEX UNIQUE SCAN             | PK_ADDRESS            |      1 |         |    0 | 00:00:01 |
|   11 |    TABLE ACCESS BY INDEX ROWID    | ADDRESS               |      1 |      49 |    1 | 00:00:01 |
---------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
------------------------------------------
* 4 - filter("EL"."ESTABLISHMENT_LICENSE_ID" IS NULL)
* 5 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID"(+))
* 7 - storage("E"."EST_CLOSED" IS NULL)
* 7 - filter("E"."EST_CLOSED" IS NULL)
* 9 - storage(SYS_OP_BLOOM_FILTER(:BF0000,"EL"."ESTABLISHMENT_ID"(+)))
* 9 - filter(SYS_OP_BLOOM_FILTER(:BF0000,"EL"."ESTABLISHMENT_ID"(+)))
* 10 - access("ADDRESS_ID"="A"."ADDRESS_ID")


Notes
-----
- This is an adaptive plan
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 01:14
    #39840272
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Внутри вьюхи VW_NOLICENSE_VK у тебя full outer join, и из-за условия
Код: plsql
1.
2.
join address A
on NL.address_id = A.address_id


в "быстром" варианте oracle понимает, что NL.address_id не должен быть null, а это поле, судя по всему, берется из таблицы ESTABLISHMENT, поэтому oracle трансформирует FULL OUTER JOIN просто в "ESTABLISHMENT left join ESTABLISHMENT_LICENSE", что видно из плана:
Victor Cookin
Код: css
1.
2.
3.
4.
5.
6.
7.
|  * 5 |       HASH JOIN OUTER             |                       |    116 |   11252 |  418 | 00:00:01 |
|    6 |        JOIN FILTER CREATE         | :BF0000               |  11579 | 1007373 |  128 | 00:00:01 |
|  * 7 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT         |  11579 | 1007373 |  128 | 00:00:01 |
|    8 |        JOIN FILTER USE            | :BF0000               | 177388 | 1773880 |  290 | 00:00:01 |
|  * 9 |         TABLE ACCESS STORAGE FULL | ESTABLISHMENT_LICENSE | 177388 | 1773880 |  290 | 00:00:01 |

* 5 - access("E"."ESTABLISHMENT_ID"="EL"."ESTABLISHMENT_ID"(+))


Это приводит к тому, что оракл снижает кардинальность этой вью до 116 строк со 178273 (при полном FOJ), а в данном случае CBO справедливо считает, что лучше использовать NL и индексный доступ по 116 строкам.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 01:17
    #39840273
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
В медленном же варианте у тебя полноценный FULL OUTER JOIN, да еще и FTS (Full Table Scan) по ADDRESS.

ps. в следующий раз сразу показывай реальные планы выполнения со статистиками, а не explain plan.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 01:29
    #39840274
кит северных морей
кит северных морей
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Victor Cookinfeagor,

Предложения есть?
попробуй дописать "where nl.address_id is not null"
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 01:34
    #39840275
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
feagorвыполнив
Код: plsql
1.
2.
explain plan for select бла-бла-бла;
select dbms_xplan.display_plan from dual


нет, лучше реальные планы со статистиками, т.е
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
select/*+ GATHER_PLAN_STATISTICS MONITOR */ бла-бла-бла;
select * from table(dbms_xplan.display_cursor('','','advanced'));
select/*+ no_monitor */
  dbms_sqltune.report_sql_monitor(sql_id => rtsm_sql_id,report_level => 'ALL',type => 'TEXT') sqlmon 
from (
   select max(m.sql_id) keep(dense_rank first order by sql_exec_start desc) rtsm_sql_id 
   from v$sql_monitor m 
   where (m.sid,m.SESSION_SERIAL#) in (select s.sid,s.serial# from v$session s where s.sid=userenv('sid'))
   and m.LAST_REFRESH_TIME>sysdate-interval'1'minute
)
where rtsm_sql_id is not null;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 03:07
    #39840279
SY
SY
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
xtender,

Все-тaки не FTS a TABLE ACCESS STORAGE FULL, т.е. EXADATA и посему я бы убедился что smart scan действительно offloading.

SY.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 04:08
    #39840282
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
SY,

Я обратил на это внимание, но посмотри примеры и вопрос внимательно:
1. В медленном варианте оффлоудить нечего, тк там FOJ и left join к address;
2. Второй вариант и так быстрый. С ним у тс вопроса не стоит, да и оффлоудинг по блум фильтру в непаралелльном запросе по небольшим несекционированным таблицам ничего обычно не даёт;
3. Заморачиваться на оффлоудинг при очевидных проблемах с планом бессмысленно и слишком рано. Кроме того, эксплейн ничего интересного про оффлоудинг не даёт и смотреть надо, как я выше показал, отчёт rtsm
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 04:14
    #39840283
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
кит северных морейVictor Cookinfeagor,

Предложения есть?
попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 04:28
    #39840284
Sayan Malakshinov
Sayan Malakshinov
Модератор форума
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
4. теоретически, конечно, возможно прибить в первом варианте хинт no_swap_join_input, чтобы попытаться форсировать оффлоудинг по address, но, очевидно, что это бессмысленно при таком малом кол-ве возвращаемых записей из нее и потенциально огромном кол-ве записей из вью, иначе индексный доступ был бы выгоднее, что определяется на этапе построения плана, а как будет и будет ли работать смарт скан - уже во время выполнения запроса
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 05:01
    #39840287
кит северных морей
кит северных морей
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
xtenderкит северных морейпропущено...

попробуй дописать "where nl.address_id is not null"а смысл? Тогда получится обычный джойн как во втором варианте (если, конечно, address id реально привязан к address.address_id

ну да. на это и расчет. обрати внимание на фильтр в строке 4 "быстрого" плана и на название вьюхи - я подозреваю, внутри неё что-то типа

select * from (
select * from establishment full join establishment_license
) where el. establishment_license_Id is null

а фулл джоин просто обернут в ещё одну вьюху, которую мы не видим из-за view merging.

то есть на самом деле ему нужны все establishment БЕЗ establishment_license, и с адресами - у кого есть. для этого не нужен FOJ между е и el.

плюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
23.07.2019, 18:05
    #39840660
Victor Cookin
Victor Cookin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
кит северных морей,

кит северных морейплюс я сильно подозреваю что во вьюхе на самом деле надо было написать where el. establishment_id is null, и тогда оптимизатор разобрался бы в этом сам.


Вы наверно имели в виду :
Код: plsql
1.
where establishment_LICENSE_id is null;



establishment_id не может быть равен null

Собственно, вот вьюха:

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
CREATE OR REPLACE FORCE VIEW MDHE.VW_NOLICENSE_VK
(ESTABLISHMENT_ID, OPENING_DATE, NAME, PHONE, NOTES, 
 EST_BUSINESS_NAME, IS_SEASONAL, SEASON_OPEN_DATE, SEASON_CLOSE_DATE, ADDRESS_ID, 
 INSPECTOR_ID)
BEQUEATH DEFINER
AS 
select Establishment_id, opening_date, name, phone, notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
address_id, inspector_id from (
select e.Establishment_id, opening_date, name, phone, e.notes, est_business_name, is_seasonal, season_open_date, season_close_date, 
address_id, inspector_id, establishment_LICENSE_id   from 
establishment e
full join 
establishment_license el
on e.establishment_id  = el.establishment_id 
where e.est_closed is NULL 
)
where establishment_LICENSE_id is null;
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему? / 25 сообщений из 44, страница 1 из 2
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 165ms
Закрыть
start [/forum/topic.php?fid=52&tablet=1&tid=1882275]:
 0ms
get settings:
 8ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 43ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 64ms
get tp. blocked users:
 2ms
others: 13ms
total:  165ms
x
x
Закрыть


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