powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кто как ответил бы на данный вопрос и почему ?
25 сообщений из 34, страница 1 из 2
Кто как ответил бы на данный вопрос и почему ?
    #39924322
adm2706
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Какой из приведенных вариантов ответов является по вашему мнению верным для следующего вопроса :

What is true about non-equijoin statement performance ?

A) The BETWEEN condition always performs less well than using the >= and <= conditions.
B) The join syntax used makes no difference to performance.
C) Table aliases can improve performance.
D) The BETWEEN condition always performs better than using the >= and <= conditions.
E) The Oracle join syntax performs better than the SQL:1999 compliant ANSI join syntax.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924325
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adm2706,

Ни одного верного.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924341
adm2706
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Тем не менее, один из этих ответов считается верным в корпорации Oracle. Интересно, какой из них это может быть ?
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924343
Фотография Elic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adm2706
Тем не менее, один из этих ответов считается верным в корпорации Oracle.
Ты можешь доказать авторство "ответов"?
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924358
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adm2706
Тем не менее, один из этих ответов считается верным в корпорации Oracle. Интересно, какой из них это может быть ?
Даже ничего не зная про предмет вопрошания, очевидно тот, который противопоставлен другим.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924363
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А что не так с ответом B ?
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924371
feagor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
The join syntax used makes no difference to performance.
а использование джоин синтаксиса разве даёт какие-то преимущества?
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924375
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
feagor,

Речь о различных вариантах записи одного и того же условия non-equijoin, в общем случае ответ B верен.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924376
booby
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoft
А что не так с ответом B ?

модальность высказывания.

Если не знаешь, что там под капотом, в такого рода случаях выбирай по модальности.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924390
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
feagor
The join syntax used makes no difference to performance.
а использование джоин синтаксиса разве даёт какие-то преимущества?

точный перевод: Использование JOIN-ов не влияет на производительность.
А он влияет. Особенно LEFT/RIGHT JOIN.
Но и JOIN конечно тоже повлияет, искать то надо.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924397
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
полудух
точный перевод: Использование JOIN-ов не влияет на производительность.

перевод неверный.

feagor
а использование джоин синтаксиса разве даёт какие-то преимущества?

в теории ANSI join и Oracle join (вероятно, речь идет о них) должны давать одинаковые результаты и производительность. на практике бывает по-разному, но в контексте теоретического вопроса это не должно иметь значения.

я бы выбрал "B".
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924398
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
кит северных морей
перевод неверный.

сказал А, говори и Б.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924399
Фотография кит северных морей
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
полудух
кит северных морей
перевод неверный.

сказал А, говори и Б.

The join syntax used makes no difference to performance.
"Используемый синтаксис join не влияет на производительность"

join syntax - это oracle join vs ansi join.
inner/left/right/full - это join type.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924409
Фотография полудух
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а, ещё одна особенность оракла
спасибо
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924410
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
полудух
точный перевод: Использование JOIN-ов не влияет на производительность.
А он влияет. Особенно LEFT/RIGHT JOIN.
Но и JOIN конечно тоже повлияет, искать то надо.

Нет, речь идет о non-equijoin .

кит северных морей
в теории ANSI join и Oracle join (вероятно, речь идет о них) должны давать одинаковые результаты и производительность. на практике бывает по-разному, но в контексте теоретического вопроса это не должно иметь значения.

Нет, non-equijoin - соединение при котором условие соединения представляет собой неравенство, в вопросах не случайно фигурирует between и то на что его можно заменить, смысл вопроса в том, что если условия эквивалентны между собой, то нет разницы в плане производительности посредством каких операторов ты опишешь условие.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924439
Фотография -2-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Автор допроса хотел спросить про трансформацию, так и нужно было спрашивать про план, не "производительность". Преобразование between и ansi-join кое-что, да стоит.
Кстати, на восьмерке запрос с ansi-join завершался быстрее.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924455
_Nikotin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Синтаксис на производительность никак непосредственно не влияет, влияет план выполнения, который может оказаться другим, в том числе и из-за синтаксиса. Если план двух эквивалентных запросов, написанных с использованием различного синтаксиса, отличается, и влечёт изменение производительности, то это следует рассматривать как дефект. Таким образом в этом случае производительность зависит от дефекта, а не от синтаксиса как такового.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924990
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_Nikotin
Синтаксис на производительность никак непосредственно не влияет, влияет план выполнения, который может оказаться другим, в том числе и из-за синтаксиса. Если план двух эквивалентных запросов, написанных с использованием различного синтаксиса, отличается, и влечёт изменение производительности, то это следует рассматривать как дефект. Таким образом в этом случае производительность зависит от дефекта, а не от синтаксиса как такового.
Я бы не рассматривал это как дефект, скорее oracle native это просто чуть более "низкоуровневый" синтаксис.

ANSI позволяет не заморачиваться с использованием inline views и лепить всё в кляузу from. Но в результате может быть создан ряд lateral views под капотом.
Которые подразуевают NL соединение а не HJ.

Oracle native же принуждает создавать inline views особенно на древних версиях чтоб обойти "a table may be outer joined to at most one other" и прочие ограничения.
Это исключает создание lateral views под капотом и оставляет больше возможностей для методов соединения.

Можно ли было реализовать преобразование ANSI -> native, чтоб не создавались lateral views? Пожалуй да.
Руками то всегда можно переписать без оных. Но что-то помешало это сделать.
Соответственно запросо-писатель выбирает: либо он всё контролирует по максимуму либо использует синтаксиеский сахарок и не парится.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39924993
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
adm2706
What is true about non-equijoin statement performance ?

Nonequijoins
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39925398
_Nikotin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кобанчег
скорее oracle native это просто чуть более "низкоуровневый" синтаксис.

Вот если если есть пример плана, котоый легко получается через native, но при этом существует эквивалентный ansi запрос, где не удаётся получить подобный план, я бы создал тикет и посмотрел что ответят, заодно бы сослася на документацию. Либо в ней баг, либо в оптимизаторе.

У меня бы подобный опыт с google поддержкой, где документация расходилась с практикой, в итоге сперва поддержка отрапортовала про баг в документации, а потом через неделю разработчики отрапортовали что баг исправлен. В этом плане Оракл впереди планеты по качеству и логичности документации.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39926368
Фотография Кобанчег
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_Nikotin
Вот если если есть пример плана, котоый легко получается через native, но при этом существует эквивалентный ansi запрос, где не удаётся получить подобный план, я бы создал тикет и посмотрел что ответят, заодно бы сослася на документацию. Либо в ней баг, либо в оптимизаторе.
Тут ключевых момента два.

1. Как уже было сказано ANSI может создавать кучу [латеральных] вьюх под капотом в результате чего треяется контроль над планом по причине того, что query block уже не тот. 13757575

2. В нативном больше требований к предикатам, и если предикат для ансишного привести а нативную форму, то трансформированный запрос чудесным образом меняется.

Код: plsql
1.
2.
3.
create table t1(id1,value) as select 1,1 from dual;
create table t2(id2,id1,value) as select 1,1,1 from dual;
create table t3(type,value) as select 'T1',1 from dual;



Код: plsql
1.
2.
3.
4.
select *
from t1
join t2 on t2.id1 = t1.id1
left join t3 on type = 'T1' and t1.value = t3.value or type = 'T2' and t2.value = t3.value;


Преобразуется в
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
SELECT "T1"."ID1"                   "ID1",
       "T1"."VALUE"                 "VALUE",
       "T2"."ID2"                   "ID2",
       "T2"."ID1"                   "ID1",
       "T2"."VALUE"                 "VALUE",
       "VW_LAT_024544ED"."ITEM_1_0" "TYPE",
       "VW_LAT_024544ED"."ITEM_2_1" "VALUE"
  FROM "T1" "T1",
       "T2" "T2",
       LATERAL((SELECT "T3"."TYPE" "ITEM_1_0", "T3"."VALUE" "ITEM_2_1"
                 FROM "T3" "T3"
                WHERE "T3"."TYPE" = 'T1'
                  AND "T1"."VALUE" = "T3"."VALUE"
                   OR "T3"."TYPE" = 'T2'
                  AND "T2"."VALUE" = "T3"."VALUE"))(+) "VW_LAT_024544ED"
 WHERE "T2"."ID1" = "T1"."ID1"



Если переписать влоб для native, то получим
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
SQL> select *
  2  from t1, t2, t3
  3  where t2.id1 = t1.id1
  4  and type(+) = 'T1' and t1.value = t3.value(+) or type(+) = 'T2' and t2.value = t3.value(+);
and type(+) = 'T1' and t1.value = t3.value(+) or type(+) = 'T2' and t2.value = t3.value(+)
                                                                             *
ERROR at line 4:
ORA-01719: outer join operator (+) not allowed in operand of OR or IN



Это можно обойти если завернуть условие соединения с t3 в case, например.
Код: plsql
1.
2.
3.
4.
select *
from t1, t2, t3
where t2.id1 = t1.id1
and (case when type(+) = 'T1' and t1.value = t3.value(+) or type(+) = 'T2' and t2.value = t3.value(+) then 1 end = 1);



Но теперь если мы так же перепишем ANSI запрос
Код: plsql
1.
2.
3.
4.
5.
select *
from t1
join t2 on t2.id1 = t1.id1
left join t3 on
(case when type = 'T1' and t1.value = t3.value or type = 'T2' and t2.value = t3.value then 1 end = 1);



То после преобразования латеральная inline view не появится.
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT "T1"."ID1"   "ID1",
       "T1"."VALUE" "VALUE",
       "T2"."ID2"   "ID2",
       "T2"."ID1"   "ID1",
       "T2"."VALUE" "VALUE",
       "T3"."TYPE"  "TYPE",
       "T3"."VALUE" "VALUE"
  FROM "T1" "T1", "T2" "T2", "T3" "T3"
 WHERE CASE
         WHEN (("T3"."TYPE"(+) = 'T1' AND "T1"."VALUE" = "T3"."VALUE"(+)) OR
              ("T3"."TYPE"(+) = 'T2' AND "T2"."VALUE" = "T3"."VALUE"(+))) THEN
          1
       END = 1
   AND "T2"."ID1" = "T1"."ID1"



Соединение с t3 можно было бы изобразить и в виде
Код: plsql
1.
decode(type(+),'T1',t1.value,'T2',t2.value) = t3.value(+)


Подобная форма для ANSI тоже бы позволила избежать создания inline view.

Но кто будет для ANSI применять case/decode трюки, если можно просто указать
Код: plsql
1.
type = 'T1' and t1.value = t3.value or type = 'T2' and t2.value = t3.value



Соответственно при использовании предиката неприменимого в native (при внешнем соединении) мы не можем добиться плана как в native из-за создания lateral view.
Это баг?

Я планы специально не приводил, думаю мысль и так ясна.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39926430
SQL*Plus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iOracleDev
Нет, non-equijoin - соединение при котором условие соединения представляет собой неравенство...
Нет.

non-equijoin - это соединение, при котором условие соединения не является равенством
или
non-equijoin - это соединение, которое выполняется не по условию равенства
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39926446
Фотография Sayan Malakshinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Модератор форума
Кобанчег
Я бы не рассматривал это как дефект, скорее oracle native это просто чуть более "низкоуровневый" синтаксис.

Ну он более "низкоуровневый" лишь по историческим причинам:
1. Oracle native синтаксис банально старее ANSI
2. Очевидно, что старый клиентский код надо было поддерживать, и полностью переписывать парсеры на ANSI синтаксис - выходит опасно и дорого. //но я несколько раз от разных людей слышал, что самих разработчиков оракл бесит эта устаревшая необходимость и они, с удовольствием бы перешли только на ANSI

Но ANSI синтаксис развивался/вается быстрее, например, в оракловом синтаксисе FULL OUTER JOIN и PARTITION JOIN не появились, а были добавлены так как они есть в ANSI. И благодаря тому, что в ANSI появились LATERAL, CROSS APPLY, и тд, наконец-то и нам разрешили древний lateral(). В итоге, имеем помесь бульдога с носорогом.

Т.е фактически оракловый синтаксис это лишь исторические "костыли" и проблемы трансформации одного к другому - это именно ошибки.

Кобанчег
lateral views под капотом.
Которые подразуевают NL соединение а не HJ.
синтаксис здесь не имеет отношения к плану. Может быть и HJ. CBO умеет работать с латералами - и аннестить умеет, и избавляться от них, и трансформировать в обычные иннер-джойны, когда надо. Я совсем недавно как раз жаловался что lateral c rownum декоррелируется когда совсем не надо и приводит к неправильным результатам, в ответ на что от оракла получил что rownum not deterministic
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39926761
iOracleDev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SQL*Plus
Нет.

non-equijoin - это соединение, при котором условие соединения не является равенством
или
non-equijoin - это соединение, которое выполняется не по условию равенства

Хотелось бы увидеть примеры условий соединений которые Oracle относит к non-equijoin и не приводимых Oracle к обычным неравенствам.
...
Рейтинг: 0 / 0
Кто как ответил бы на данный вопрос и почему ?
    #39926805
Alexander Anokhin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
xtender
Я совсем недавно как раз жаловался что lateral c rownum декоррелируется когда совсем не надо и приводит к неправильным результатам, в ответ на что от оракла получил что rownum not deterministic

Что там было?
...
Рейтинг: 0 / 0
25 сообщений из 34, страница 1 из 2
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Кто как ответил бы на данный вопрос и почему ?
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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