ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
25 сообщений из 44, страница 1 из 2
  1  все
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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:28
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838450
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-2-
Участник
Victor Cookin,

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

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

Предложения есть?
...
Рейтинг: 0 / 0
17.07.2019, 20:30
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838470
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Cookin
Участник
LEFT JOIN?
...
Рейтинг: 0 / 0
17.07.2019, 20:34
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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
17.07.2019, 20:37
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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, 00:06
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838938
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Cookin
Участник
Изя КацманОптимизёр выбрал такой план.
Он не оптимален
...
Рейтинг: 0 / 0
18.07.2019, 20:23
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39838943
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
Victor CookinИзя КацманОптимизёр выбрал такой план.
Он не оптималенпотому что запрос (и девелопер?) "не оптимален"
...
Рейтинг: 0 / 0
18.07.2019, 20:55
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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
18.07.2019, 23:13
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840092
Фотография Victor Cookin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Cookin
Участник
Up
...
Рейтинг: 0 / 0
22.07.2019, 17:39
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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, 18: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
22.07.2019, 23:12
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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:14
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840273
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
В медленном же варианте у тебя полноценный FULL OUTER JOIN, да еще и FTS (Full Table Scan) по ADDRESS.

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

Предложения есть?
попробуй дописать "where nl.address_id is not null"
...
Рейтинг: 0 / 0
23.07.2019, 01:29
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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, 01:34
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840279
Фотография SY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SY
Участник
xtender,

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

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

Я обратил на это внимание, но посмотри примеры и вопрос внимательно:
1. В медленном варианте оффлоудить нечего, тк там FOJ и left join к address;
2. Второй вариант и так быстрый. С ним у тс вопроса не стоит, да и оффлоудинг по блум фильтру в непаралелльном запросе по небольшим несекционированным таблицам ничего обычно не даёт;
3. Заморачиваться на оффлоудинг при очевидных проблемах с планом бессмысленно и слишком рано. Кроме того, эксплейн ничего интересного про оффлоудинг не даёт и смотреть надо, как я выше показал, отчёт rtsm
...
Рейтинг: 0 / 0
23.07.2019, 04:08
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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:14
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #39840284
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sayan Malakshinov
Модератор форума
4. теоретически, конечно, возможно прибить в первом варианте хинт no_swap_join_input, чтобы попытаться форсировать оффлоудинг по address, но, очевидно, что это бессмысленно при таком малом кол-ве возвращаемых записей из нее и потенциально огромном кол-ве записей из вью, иначе индексный доступ был бы выгоднее, что определяется на этапе построения плана, а как будет и будет ли работать смарт скан - уже во время выполнения запроса
...
Рейтинг: 0 / 0
23.07.2019, 04:28
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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, 05:01
| Ответить | Цитировать | Написать  
(+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
    #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
23.07.2019, 18:05
| Ответить | Цитировать | Написать  
25 сообщений из 44, страница 1 из 2
  1  все
Форумы / Oracle [игнор отключен] [закрыт для гостей] / (+) уввеличивает время исполнения, даже когда результат один и тот же. Почему?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&msg=39840273&tid=1882275]:
 0ms
get settings:
 11ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 39ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 62ms
get tp. blocked users:
 1ms
others: 273ms
total:  423ms
созд. / загр.: 423ms
x
x
Закрыть


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