Здравствуйте, Arioch, Вы писали:
M>> Это противоречит и стандарту A>Цитата под руками есть?
Ну про delete уже приводили, а общий случай искать лень, но это же очевидно.
M>> и здравому смыслу. A>Есть зоть один сервер, где бы ни-че-го не противоречило здравому смыслу?
Ну практически все сервера, за исключением мелких недочетов, здравому смыслу не противоречат. Этот же недочет мелким не назовешь.
A>В данном случае, никаих вариантов последовательности нет.
Во-первых они потенциально возможны, а во вторых, я не считаю нормальной ситуацию, когда простейший self join может положить сервер напрочь.
Здравствуйте, Arioch, Вы писали:
A>Где тут join ??? self join — общий случай, когда оператор/ы замыкает отношение само на себя. Подозреваю, что проблемы могут быть не только с insert'ом
A>И сервер не ляжет, он займет максимум места на таблицу/файл, потом скажет A>облом и rollback.
Ага, а процессор эта операция совсем не грузит? И очередь к диску не выстраивается? И время на откат этой кучи мусора и опять-таки дисковых операций не требуется?
При более-менее серьезной нагрузке такой запрос положит сервер на раз-два-три.
A>Ну не хорошо, но грабли везде есть.
Нифига себе — нехорошо... Это плохо...
Здравствуйте, Romkin, Вы писали:
R>Почему ты так решил?
Я уже написал почему. Первое что делает оптимизатор — это путем перестановок операторов добивается более эффективного получения того же самого результата. А при такой ситуации особо не по переставляешь.
R>Оптимизатор нормально уже работает в FB.
"Не верю" (c)
R>Нет, это повод не писать диких запросов
Да какой он там дикий? Тут как по минному полю — шаг в сторону и все, баста карапузики...
Здравствуйте, Merle, Вы писали:
R>> Оптимизатор нормально уже работает в FB. M> M> "Не верю" (c)
Правильнее будет сказать, что он стал заметно лучше. Если и тут не веришь, вызываю на дуэль
А насчет сабжа — весьма некузяво это, разумеется. Мягко говоря. Самое неприятное, что это не то, чтобы бага, а скорее "as designed"... И безболезненно сменить поведение будет ой как нелегко. Эээххх...
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Romkin, Вы писали:
R>>Почему ты так решил? M>Я уже написал почему. Первое что делает оптимизатор — это путем перестановок операторов добивается более эффективного получения того же самого результата. А при такой ситуации особо не по переставляешь.
И что? Я переставляю. Нормально.
R>>Оптимизатор нормально уже работает в FB. M>"Не верю" (c)
Не хочешь — не верь
R>>Нет, это повод не писать диких запросов M>Да какой он там дикий? Тут как по минному полю — шаг в сторону и все, баста карапузики...
Ну-ну. За N лет работы с IB у меня впечатления работы сапером не было. В отличие от MSSQL, кстати, там для меня ужастики были (я посмотрел MSSQL6.5 и офигел в свое время).
Здравствуйте, Romkin, Вы писали:
R>И что? Я переставляю. Нормально.
Хха.. Во-первых у тебя результат запроса будет другой, но, допустим, что ты переставил удачно... Но через полдня статистика поменялась и выгодным стал другой план запроса и, соответственно, порядок выполнения операторов.
Чего делать будешь? Опять менять?
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Romkin, Вы писали:
R>>И что? Я переставляю. Нормально. M>Хха.. Во-первых у тебя результат запроса будет другой, но, допустим, что ты переставил удачно... Но через полдня статистика поменялась и выгодным стал другой план запроса и, соответственно, порядок выполнения операторов. M>Чего делать будешь? Опять менять?
Млин, не так переставляю
for select ID
from TEST1
GROUP BY ID
HAVING count(ID) > 1
into :ID
do
delete from TEST1 where ID = :ID;
Здравствуйте, Romkin, Вы писали:
R>Млин, не так переставляю
И так каждый раз? Здесь я говорю уже не о конкретном примере. Оптимизатор в принципе не может свободно менять порядок операторов, потому что это может привести к искажению результата...
То есть в IB, по прежнему, приходится жестко прописывать запросы хинтами, что не есть гуд.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Romkin, Вы писали:
R>>Млин, не так переставляю M>И так каждый раз? Здесь я говорю уже не о конкретном примере. Оптимизатор в принципе не может свободно менять порядок операторов, потому что это может привести к искажению результата... M>То есть в IB, по прежнему, приходится жестко прописывать запросы хинтами, что не есть гуд.
Никаких хинтов Зачем? При таком написании оптимизатор подключит оптимальный индекс в том и другом запросе.
И так каждый раз. Нету у меня в БД вложенных подзапросов и очень мало джойнов. VIEW нет совершенно, вместо них select SP. Так повелось еще с IB 5.6, максимальная скорость и оптимальный план. Дело в том, что в IB получить набор записей из SP — раз плюнуть
Здравствуйте, Romkin, Вы писали:
R> Нету у меня в БД вложенных подзапросов и очень мало джойнов.
Счастливчик..
Довольно большой процент задач можно свести к простым запросам, но как правило, хороший оптимизатор спарвляется с этим эффективнее.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Romkin, Вы писали:
R>> Нету у меня в БД вложенных подзапросов и очень мало джойнов. M>Счастливчик.. M>Довольно большой процент задач можно свести к простым запросам, но как правило, хороший оптимизатор спарвляется с этим эффективнее.
Дык их нет потому, что я их разворачиваю в for select. И получается весьма неплохо.
Например, есть документ DOC, в нем Client_ID со ссылкой на CLIENT(ID, name). Ессно, хочется запрос (допустим):
select DOC.NUM, DOC.Client_ID, CLIENT.name as Client_name
from DOC left join CLIENT on DOC.Client_ID = CLIENT.Client_ID
where DOC.NUM = :FNUM;
Так?
create procedure LIST_DOC (FNUM integer)
returns (NUM integer, Client_ID integer, Client_Name varchar(100))
as
begin
for select NUM, Client_ID
from DOC
where DOC.NUM = :FNUM
into :NUM, :Client_ID
do begin
Client_Name = NULL;
select name from client
where Client_ID = :Client_ID;
suspend;
end
end;
А так? Вызов примитивен: Select * from LIST_DOC(:FNUM), но при наличии многих джойнов (а не одного, как здесь) план будет гораздо эффективнее во втором случае. Соответственно, выигрыш в скорости — в разы.
Так уж устроен оптимизатор в IB, он действительно примитивен. Ждем FB2
Здравствуйте, dimitr, Вы писали:
D>А насчет сабжа — весьма некузяво это, разумеется. Мягко говоря. Самое неприятное, что это не то, чтобы бага, а скорее "as designed"... И безболезненно сменить поведение будет ой как нелегко. Эээххх...
а как насчет маштабируемости? ежели подзапрос "перевыполняется" на "каждом шаге"?
это же пинцет какой-то. и это в простых случаях! а ежели три вложенных друг в друга? ужас!
... << RSDN@Home 1.1.3 beta 1 >>
— сколько программистов надо чтобы заменить сгоревшую лампочку?
— сколько не бери, а лампочку не поменять — проблема аппаратная, программным путем не решается...
Здравствуйте, _MarlboroMan_, Вы писали:
_MM_>Здравствуйте, dimitr, Вы писали:
_MM_>а как насчет маштабируемости? ежели подзапрос "перевыполняется" на "каждом шаге"?
_MM_>это же пинцет какой-то. и это в простых случаях! а ежели три вложенных друг в друга? ужас!
Как правило, вложенный запрос зависит от внешнего Если не зависит — его просто надо вынести в наружный цикл. И получается кузяво
Здравствуйте, Romkin, Вы писали:
R>А так? Вызов примитивен: Select * from LIST_DOC(:FNUM), но при наличии многих джойнов (а не одного, как здесь) план будет гораздо эффективнее во втором случае. Соответственно, выигрыш в скорости — в разы. R>Так уж устроен оптимизатор в IB, он действительно примитивен. Ждем FB2
Пипец... Это покруче хинтов, ты по сути, полностью прописываешь ход выполнения запроса не оставляя серверу ни шанса вмешаться. Дааа....
А ведь встречаются ситуации, когда Hash или Merge join в десятки, если не в сотни раз выгоднее, и фиг ты это дело сэмулируешь на таких циклах. Да банально, оптимальный порядок объединения таблиц может меняться вообще от запроса к запросу...
А ты еще на MS 6.5 жаловался, нет, ребята IB — это для маньяков..
Здравствуйте, Merle, Вы писали:
M>Пипец... Это покруче хинтов, ты по сути, полностью прописываешь ход выполнения запроса не оставляя серверу ни шанса вмешаться. Дааа.... M>А ведь встречаются ситуации, когда Hash или Merge join в десятки, если не в сотни раз выгоднее, и фиг ты это дело сэмулируешь на таких циклах. Да банально, оптимальный порядок объединения таблиц может меняться вообще от запроса к запросу... M>А ты еще на MS 6.5 жаловался, нет, ребята IB — это для маньяков..
Когда join быстрее получается — делаю его. Не догма. Выбирается то, что быстрее.
Здравствуйте, Romkin, Вы писали:
R> Когда join быстрее получается — делаю его. Не догма. Выбирается то, что быстрее.
Дык в том-то и засада, что сейчас быстрее один join, а через полчаса другой... Не на выбираешься.
Привет, Merle!
Вы пишешь 19 марта 2004:
R>> Когда join быстрее получается — делаю его. Не догма. Выбирается то, что быстрее. M> Дык в том-то и засада, что сейчас быстрее один join, а через полчаса другой... Не на выбираешься.
Тут ты не прав. Давайте обсуждать вкусовые качества устриц с теми кто их пробовал ;о)
Здравствуйте, Alex.Che, Вы писали:
AC>Тут ты не прав. Давайте обсуждать вкусовые качества устриц с теми кто их пробовал ;о)
Ты про каких устриц? И в чем я не прав?
Хочешь сказать, что в большинстве систем оптимальный план большинства запросов определяетя на этапе разработки?
Так не бывает.
Мы уже победили, просто это еще не так заметно...
