План запроса с IN

← →
kaif © (2004-04-29 00:46) [0]

Допустим, яделаю простой запрос:
SELECT * FROM T WHERE ID = 15
получаю такой план:
PLAN (GOODS INDEX (RDB$PRIMARY101))
Я так понимаю, что это использование индекса RDB$PRIMARY101
-----------------------
Теперь я делаю такой запрос
SELECT * FROM T WHERE ID IN (15,16)
получаю такой план:
PLAN (GOODS INDEX (RDB$PRIMARY101,RDB$PRIMARY101))
------------------------
Наконец, я делаю так:
SELECT * FROM T WHERE ID IN (15,16,17,18,19)
и получаю такой план:
PLAN (GOODS INDEX (RDB$PRIMARY101,RDB$PRIMARY101,RDB$PRIMARY101,RDB$PRIMARY101,RDB$PRIMARY101))
------------------------
Можно заметить, что один и тот же индекс перечисляется столько раз, сколько имеется элементов в явно указанном множестве.

У меня вопрос к знатокам синтаксиса PLAN.
Что означает эта конструкция с перечислением 5 раз одного и того же индекса?

← →
Vemer © (2004-04-29 01:12) [1]

Не крутой знаток, но могу предположить, что IN согласно своей сущности перебирает все множество. Поэтому запросов с IN следует стараться избегать под IB. Например с помощью Exist или Left Join с проверкой на Null.

← →
Petr.V Abramov (2004-04-29 02:52) [2]

IN преобразуется в OR.
P.S. скажите спасибо, что не в UNION :)

← →
kaif © (2004-04-29 16:16) [3]

2 Petr.V Abramov (29.04.04 02:52) [2]
IN преобразуется в OR.
Спасибо. Я попробовал переделать в OR - действительно, план тот же. То есть перечисление индексов, судя по всему, соответствует последовательности проверок всех условий.
Или я не прав?
К сожалению, информация по планам на ibase.ru настолько скудная... Кроме одного документа за 1993 г. практически ничего содержательного там я не нашел. Может кто знает еще какие-то источники? Я экспериментирую с вложенными запросами и мне хотелось бы очень точно понимать синтакис планов.

← →
Johnmen © (2004-04-29 17:03) [4]

>kaif © (29.04.04 16:16) [3]

На http://www.krista.ru/ib/ ходил ?

← →
Petr V. Abramov © (2004-04-29 17:10) [5]

> Или я не прав?
Прав. А как, по-Вашему, еще можно реализовать IN ? Другой вопрос, что IN ( select X from <откуда-то>) должен преобразовываться в join, что, по слухам, делается не всегда. Хотя за FB 1.5 я такого не замечал.

← →
kaif © (2004-04-29 17:11) [6]

Я там только "Плановое хозяйство" смотрел. Сейчас вижу, что там еще какая-то информация есть. Спасибо.

← →
kaif © (2004-04-29 17:13) [7]

2 Johnmen © (29.04.04 17:03) [4]
Да, это именно тот материал, который мне как-то уже попадался и я все не мог его найти. Спасибо! Там о подзапросах много написано.

← →
Johnmen © (2004-04-29 17:28) [8]

>Petr V. Abramov © (29.04.04 17:10) [5]
>А как, по-Вашему, еще можно реализовать IN ?

Смотря какой IN.

← →
Petr V. Abramov © (2004-04-29 17:52) [9]

> Johnmen © (29.04.04 17:28) [8]
> Смотря какой IN.
Ну какой? :)

← →
Johnmen © (2004-04-29 18:08) [10]

>Petr V. Abramov © (29.04.04 17:52) [9]

Есть же 2 реализации IN.
1. (x1,x2,...xn)
2. (SELECT x FROM ...)
Второй можно реализовать и по-другому.

← →
Petr V. Abramov © (2004-04-29 18:13) [11]

> Johnmen © (29.04.04 18:08) [10]
Второй - нужно по-другому. Я и не спорю, см. [5]

← →
Johnmen © (2004-04-29 18:20) [12]

>Petr V. Abramov ©
>должен преобразовываться в join,

Вот это я не понял ([5])... И это породило [8]&[10]

← →
kaif © (2004-04-29 18:35) [13]

Почему бы не интерпретировать вхождение в множество, как INNER JOIN ? Можно же рассматривать множество так же, как результат выборки SELECT x FROM ... Упорядочить (SORT) и объединить с помощью какого-нибудь MERGE. Зачем реализовывать это как перечисление отдельных условий с OR? Странно как-то это все... А что, разве объединение с SELECT x FROM ... не то же самое в конечном итоге? Тоже ведь можно представить в виде огромного кол-ва условий OR. Но так не делают.

← →
Petr V. Abramov © (2004-04-29 18:41) [14]

А во что же оно должно преобразовываться? Разве
select *
from T1 where Y in ( select X from T2)

не то же самое, что

select T1.*
from T1, T2
where T1.Y = T2.X

Другой случай, когда подзапрос сильно навороченный и никак не связан с T1. Но тут уже грань между join и перебором стирается. Кстати, есть ссылки на алгоритмы join в FB?

← →
Petr V. Abramov © (2004-04-29 18:44) [15]

> Кстати, есть ссылки на алгоритмы join в FB?
Есть :)

> Johnmen © (29.04.04 18:20) [12]
Наверно, под JOIN Вы поняли вполне конкретный алгоритм соединения таблиц, а я имел в виду операцию соединения как таковую

Я и говорю. Если

select *
from T1 where Y in ( select X from T2)

то же самое, что

select T1.*
from T1, T2
where T1.Y = T2.X

то и

select *
from T1 where Y in (1,2,3)

то же самое, что и

select T1.*
from T1, T2
where T1.Y = T2.X

где T2 - виртуальная таблица вида:

X
===
1
2
3

Просто нужно упорядочить это множество и все обычные алгоритмы объединений (какие бы они не были - не важно), работающие для объединения двух простых таблиц будут работать точно так же.

> kaif © (29.04.04 19:55) [17]
А зачем лишний раз чего-то упорядочивать? Это недешево.
"обычные алгоритмы объединений" ни на каком волшебстве не основаны. Та же операция JOIN - обычное лазание по индексам, с пердварительной прикидкой, у какой таблицы cardinality с учетом условий отбора - меньше. Четкого описания этого алгоритма (nested loops) конкретно для IB я не видел, но видел для Oracle, и у меня есть подозрение, что его основе лет 50 и он используется всеми СУБД. Ибо простой :) О том, что IB использует его же, косвенно сужу по порядку записей, возвращаемых запросами.

>Petr V. Abramov © (29.04.04 18:41) [14]
>А во что же оно должно преобразовываться? Разве
> select *
> from T1 where Y in ( select X from T2)

> не то же самое, что

> select T1.*
> from T1, T2
> where T1.Y = T2.X

Конечно же это не одно и то же !!!

2 Johnmen © (30.04.04 09:57) [19]
Конечно же это не одно и то же !!!

А по-моему одно и то же, если абстрагироваться от списка возвращаемых колонок и сконцентрировать свое внимание на списке возвращаемых из первой таблицы строк. Во всяком случае интуитивно понятно, что имелось в виду под "одно и то же". Одни и те же записи из первой таблицы.

План запроса с IN Найти похожие ветки