Re: Удаление по сложному условию

2011-06-19 Пенетрантность Tonal 
17.06.2011 13:16, Dmitri Kuzmenko пишет:
> здрасьте. поставь вместо delete select, и будет то же самое.
> select from SYMP2REMEDS  where sr.id in 
Про select вопросов нет.
Хочется написать именно delete без «паразитного» where sr.id in 
-- 
Александр Замараев

Re: Удаление по сложному условию

2011-06-17 Пенетрантность Dmitry Yemanov 

14.06.2011 14:05, Tonal пишет:


Из большой таблички нужно удалить записи по сложному условию.
План для условия вполне нормальный.
Но когда включаешь его в delete выплывает NATURAL.


"Нормальный план" - у подзапроса внутри IN, для внешней таблицы есс-но 
будет натурал, это ведь лишний паразитный джойн.



Есть ли какой-нибудь способ не проходить для этого всю табличку?
Можно конечно преобразовать в execute block, но хотелось бы более
декларативного и стандартного способа.
Может что предполагается в 3-ке или на будущее? :)


Предполагается.


--
Дмитрий Еманов

Re: Удаление по сложному условию

2011-06-17 Пенетрантность Dmitry Yemanov 

17.06.2011 8:26, Tonal пишет:


Кстати и в плане бы было бы хорошо как-то различать натурал, который
полный перебор и который позиционирование по rdb$db_key - вопросов бы
меньше возникало. :)


В плане это вполне видно. Идем перечитывать мою старую статью по методам 
доступа, там это есть.



--
Дмитрий Еманов

Re: Удаление по сложному условию

2011-06-16 Пенетрантность Dmitri Kuzmenko 

Hello, Tonal!

Tonal wrote:


Вроде бы стандартная ситуация и оптимизатор мог бы сам преобразовать в
соответствующий for select...


здрасьте. поставь вместо delete select, и будет то же самое.
select from SYMP2REMEDS  where sr.id in 

--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34

Re: Удаление по сложному условию

2011-06-16 Пенетрантность Tonal 
17.06.2011 03:51, Arioch пишет:
>> Вроде бы стандартная ситуация и оптимизатор мог бы сам преобразовать в
>> соответствующий for select...
> Если правда, что "позиционирование по rdb$db_key считается натуралом," -
> то может он и преобразовывает ?
Вот и хочется услышать комментарии от разработчиков.
Уже преобразовывает, или в планах/поставить в трекер, или присылай патч
если такой умный/плати деньгу если такой богатый. :)

Кстати и в плане бы было бы хорошо как-то различать натурал, который
полный перебор и который позиционирование по rdb$db_key - вопросов бы
меньше возникало. :)
-- 
Александр Замараев

Re: Удаление по сложному условию

2011-06-16 Пенетрантность Arioch 
В письме от Tue, 14 Jun 2011 14:58:14 +0400, Tonal  
 сообщал:




А for select по условию без натурала с выборкой rdb$db_key и удалением
по нему не спасает?



Вроде бы стандартная ситуация и оптимизатор мог бы сам преобразовать в
соответствующий for select...


Если правда, что "позиционирование по rdb$db_key считается натуралом," -  
то может он и преобразовывает ?


--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Удаление по сложному условию

2011-06-14 Пенетрантность Tonal 
14.06.2011 17:26, Sergey Mereutsa пишет:
> А for select по условию без натурала с выборкой rdb$db_key и удалением
> по нему не спасает?
for select - это уже execute block или сохранёнка.
А хотелось бы одним delete обойтись.

Вроде бы стандартная ситуация и оптимизатор мог бы сам преобразовать в
соответствующий for select...
-- 
Александр Замараев

Re: Удаление по сложному условию

2011-06-14 Пенетрантность Sergey Mereutsa 
Привет!

> Из большой таблички нужно удалить записи по сложному условию.
> План для условия вполне нормальный.
> Но когда включаешь его в delete выплывает NATURAL.

А for select по условию без натурала с выборкой rdb$db_key и удалением
по нему не спасает?

Правда, позиционирование по rdb$db_key считается натуралом, но на это
можно не обращать внимания :)


-- 
Best regards,
 Sergeymailto:gebele...@gmail.com

Удаление по сложному условию

2011-06-14 Пенетрантность Tonal 
Привет всем. :)

Из большой таблички нужно удалить записи по сложному условию.
План для условия вполне нормальный.
Но когда включаешь его в delete выплывает NATURAL.

Есть ли какой-нибудь способ не проходить для этого всю табличку?
Можно конечно преобразовать в execute block, но хотелось бы более
декларативного и стандартного способа.
Может что предполагается в 3-ке или на будущее? :)

Пример запроса на удаление:
delete from SYMP2REMEDS sr
where sr.ID in (
  select sr_dst.ID from SYMP2REMEDS sr_dst
  inner join SYMP2REMEDS_ORIGIN sro on sro.OBJ_ID = sr_dst.ID
  inner join SYMP2REMEDS sr_src on sr_src.ID = sro.ORIGIN_ID
  inner join SYMP2REMEDS_ORIGIN sro1 on sro1.OBJ_ID = sr_dst.ID
  where sr_dst.SYM_ID = ?--?DST_ID
  and sr_src.SYM_ID = ?--?SRC_ID
  group by 1
  having count (*) = 1
)
План:
PLAN SORT (JOIN (JOIN (SR_DST INDEX (PK_SYMP2REMEDS), SRO INDEX
(FK_SYMP2REMEDS_ORIGIN_OBJ_ID), SRO1 INDEX
(FK_SYMP2REMEDS_ORIGIN_OBJ_ID)), SR_SRC INDEX (PK_SYMP2REMEDS)))
PLAN (SR NATURAL)

Выжимка из табличек:
CREATE TABLE SYMP2REMEDS
(
  ID D_BIG_ID,
  SYM_ID D_ID,
  CONSTRAINT PK_SYMP2REMEDS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2REMEDS_SYM_ID FOREIGN KEY (SYM_ID) REFERENCES
SYMPTOMS (ID) ON DELETE CASCADE
);
CREATE TABLE SYMP2REMEDS_ORIGIN
(
  OBJ_ID D_BIG_ID,
  ORIGIN_ID D_BIG_ID,
  CONSTRAINT FK_SYMP2REMEDS_ORIGIN_OBJ_ID
  FOREIGN KEY (OBJ_ID) REFERENCES SYMP2REMEDS (ID) ON DELETE CASCADE;
  CONSTRAINT FK_SYMP2REMEDS_ORIGIN_ORIGIN_ID
  FOREIGN KEY (ORIGIN_ID) REFERENCES SYMP2REMEDS (ID) ON DELETE CASCADE;
);
-- 
Александр Замараев