Есть две таблицы - images и images_sel.

Таблицы объединены по пк images.image_uid и внешнему ключу images_sel.image_uid. Таблица image_uid состоит из одного поля - image_uid.

Нужно придумать запрос, который бы удаял записи в images, которые присутствуют в images_sel.

Делаю так:

delete from images where image_uid in (select image_uid from images_sel)

медленно, из-за PLAN (IMAGES NATURAL)

Вынести в отдельное поле в images не предлагать, как раз от этого пытаюсь избавиться.

Записей в images может быть десятки миллионов, в images_sel обычно 10-100.

курсор для связки таблиц и DELETE WHERE CURRENT OF ?


> delete from images where image_uid in (select image_uid
> from images_sel)
>
> медленно, из-за PLAN (IMAGES NATURAL)


странно.

> курсор для связки таблиц и DELETE WHERE CURRENT OF ?


ХП + цикл с курсором по images_sel?

>Таблица image_uid состоит из одного поля - image_uid.

читать: Таблица images_sel состоит из одного поля - image_uid.

> Дмитрий Белькевич   (10.06.10 22:33)  


> where image_uid in (select

IN лучше не использовать. тормоза обеспечены. тем более в fb1.0
EXISTS - должно помочь

Дмитрий Белькевич   (10.06.10 23:07) [2]

Цикл с курсором по связке таблиц.

> EXISTS - должно помочь


Пробую так:




без изменений - читается весь images неиндексированно

PLAN (IMAGES_SEL INDEX (FK_IMAGES_SEL_1))
PLAN (IMAGES NATURAL)

>Дмитрий Белькевич   (11.06.10 10:02) [6]
>без изменений - читается весь images неиндексированно
разумеется

удаление в цикле по images_sel, как Вам предлагали ранее, попробовали?
каков результат?

> удаление в цикле по images_sel, как Вам предлагали ранее,
>  попробовали?


Синтаксис не знаю. Попробовал несколько отсюда:

http://google.com/codesearch?hl=ru&start=70&sa=N&filter=0&q=%22WHERE+CURRENT+OF%22+lang:sql

ничего не подходит.

>Дмитрий Белькевич   (11.06.10 13:38) [8]
>Синтаксис не знаю.
ibase.ru

> for select image_uid from images_sel into :uiddo  begin
>    delete from images where image_uid = :uid  end


Таки да. Всем спасибо за обсуждение.

Все-таки недоделанный он, этот Firebird. Нормальные СУБД умеют обрабатывать запрос в [0] (с IN) быстро и безболезененно

> Игорь Шевченко ©   (11.06.10 20:36) [12]


> Все-таки недоделанный он, этот Firebird.

Доделанный уже. FB1.0 это, по сути тот же IB6

turbouser ©   (11.06.10 21:50) [13]

Это я в курсе слегка. FB появился, когда Borland исходники IB6 выложил в открытый доступ.

И с тех пор у него проблема с оптимизацией подзапросов.

> Игорь Шевченко ©   (11.06.10 22:30) [14]

в текущих версиях вроде нормально

turbouser ©   (11.06.10 22:31) [15]

Я рад за разработчиков, но мы как в свое время наткнулись, так избегали писать запросы определенного вида в системе, ориентированной на IB6/FBx. Не переписывать же каждый раз запросы при появлении новых версий СУБД, верно ?

Это всё я в 2.1.1 тестировал, если что. Просто мне совместимость с 1.0 нужна. А так - то и в 2.1.1 работает всё так же.

> Записей в images может быть десятки миллионов, в images_sel
> обычно 10-100.

а оптимизатор об этом знает?
может, статистики собрать?