DY Tonal [EMAIL PROTECTED] wrote:
DY
DY А зачем, он же не корелированный?
DY Не верь глазам своим (с)
да, вот я тут тоже, написал запрос delete ..where in ( select...
подумал, тормозить же будет наверное, ведь запрос в select много записей
возвратит.
Ан нет. Смотрю план... Ба, да
Tonal пишет:
Занабобилость удалять из таблицы 100 первых записей.
Вроде бы просто:
delete from CLIENTS C
where C.IDCLIENT in (
select first 100 C.IDCLIENT
from CLIENTS C
order by C.IDCLIENT
)
Для проверки нарисовал запросик:
select C.IDCLIENT
from CLIENTS C
where C.IDCLIENT in (
Tonal пишет:
Действительно выдаёт 10 первых.
Если написать
delete from CLIENTS C0
where C0.IDCLIENT (
select first 1 skip 10 C.IDCLIENT
from CLIENTS C
order by C.IDCLIENT
)
то именно 10 и удаляются. ;-)
Есть ли какие то подводные камни в этом решении?
Привет!
Если поле IDCLIENT
И всё-таки поведение оптимизатора в этом случае некорректно.
Когда во вложенном запросе есть first или skip его нельзя
преобразовывать в exists!
Для проверки нарисовал запросик:
select C.IDCLIENT
from CLIENTS C
where C.IDCLIENT in (
select first 100 C.IDCLIENT
from CLIENTS C
order by
Когда во вложенном запросе есть first или skip его нельзя преобразовывать
в exists!
2.0 этого не делает.
Это славно! ;-)
Вот только на DELETE это никак не сказывается - там
другая проблема работает.
А если в подзапросе для DELETE-а будет сортировка не по первичному
ключу? Тоже сползание
Hello, Dmitry!
You wrote on Fri, 31 Mar 2006 09:20:40 +0400:
DY Патамучта DELETE наступает сам себе на яйцы.
В хумор, однозначно!!! :-
With best regards, Alex Pugovko.
Dmitry Yemanov пишет:
А если в подзапросе для DELETE-а будет сортировка не по первичному ключу?
Пофиг.
Почему вообще это происходит?
Патамучта DELETE наступает сам себе на яйцы.
Содержательный ответ. ;-)
Получается, что в DELETE вообще нельзя in использовать?
И вот такой DELETE удалит
7 matches
Mail list logo
