Select из ХП и таблицы в одном запросе

← →
Жук © (2003-05-29 11:49) [0]

Запрос :
select t.*,p.rez from mtable t,mproc(input_par) p order by p.rez
Сильно ли влияет отбор записей одновременно из таблицы и ХП на скорость выполнения запроса и индексацию ?

← →
Johnmen © (2003-05-29 12:03) [1]

>Сильно ли влияет ... на скорость ...

По сравнению с чем ?

← →
Alexandr © (2003-05-29 12:18) [2]

1) где условие соединения?
2) А не упадет?
3) Мож проще все это запихать в процедуру?
4) На все вопросы даст ответ план

← →
Жук © (2003-05-29 13:14) [3]

> Johnmen © (29.05.03 12:03)
>
> По сравнению с чем ?

Ну хоть с той же ХП.

> Alexandr © (29.05.03 12:18)
> 1) где условие соединения?
> 2) А не упадет?
> 3) Мож проще все это запихать в процедуру?
> 4) На все вопросы даст ответ план

1) Нет
2) Кто ?
3) Не знаю. Всё надо смотреть по конкретике.
4) План весь выкурили в http://delphimaster.net/view/15-1053950176/ :-)))

← →
Johnmen © (2003-05-29 13:20) [4]

Слишком неконкретные исходные данные для нормального ответа...:)

← →
Жук © (2003-05-29 13:28) [5]

> Johnmen © (29.05.03 13:20)
> Слишком неконкретные исходные данные для нормального ответа...:)

Сам вижу. Попробую сформулировать. Вот :

Romkin © (28.05.03 12:28)
А вот соединять в запросе таблицу и ХП - очень дурной тон... Мне, например, такого соединения никогда не надо было.

Далее :

Danilka © (29.05.03 09:04)
дурной тон потому-что соединение будет native, индексы не будут использоваться.

Верно ли всё это ?

← →
Zacho © (2003-05-29 13:30) [6]

Собственно, насколько я понимаю, в основном вопрос заключается в том: используются ли индексы для соединения таблицы и результатов, возвращяемых хранимой процедурой в запросах типа SELECT ... FROM TABLE JOIN SP ON ..
Я всегда считал, что нет, но что-то засомневался :-) Кто нибудь может аргументированно объяснить ?

← →
Жук © (2003-05-29 14:01) [7]

2 Johnmen
Евгений ! Вся надежда на вас !!!

← →
Desdechado © (2003-05-29 14:21) [8]

На форуме interbase-world промелькнула инфа, что Firebird 1.5 уже умеет объединять результат ХП с таблицами по индексу. Насколько эффективно - не знаю.
Ну а остальные - традиционно нет.

А в запросе автора ветки объединения нет, поэтому будет простое декартово произведение, в котором исп-е индексов бессмысленно.

Ну и "индексация" - это ПРОЦЕСС СОЗДАНИЯ (или поддержания) индекса, а не его использования ...

← →
Johnmen © (2003-05-29 14:27) [9]

Как показывают экперименты, при таких соединениях (таблица с ХП) индексы НЕ ИСПОЛЬЗУЮТСЯ ! Что понятно.
Используется альтернативное соединение MERGE для предварительно отсортированных потоков (SORT), что и видно в плане выполнения запроса.
Вот такая коротенькая имха...:)))

← →
Zacho © (2003-05-29 14:33) [10]

> Desdechado © (29.05.03 14:21)

> Johnmen © (29.05.03 14:27)

Так я и думал. И мои эксперименты это подтверждали. Но меня сбил с толку план, приведенный Жук © в http://delphimaster.net/view/15-1053950176/
Или я как-то неправильно этот план понял ? Или просто плохо его рассмотрел ? :-)

← →
Жук © (2003-05-29 14:42) [11]

> Johnmen © (29.05.03 14:27)

Просто зарезали. :-) Щас буду юзать эти объединения, пока сервер не уроню...

> Zacho © (29.05.03 14:33)

Наверное плохо рассмотрели. :-)

← →
Desdechado © (2003-05-29 14:51) [12]

2 Zacho © (29.05.03 14:33)
приведенный план явно относился к содержимому ХП, а не к запросу

← →
Zacho © (2003-05-29 14:54) [13]

> Desdechado © (29.05.03 14:51)

Вот это похоже на правду :-)

← →
Жук © (2003-05-29 15:03) [14]

> Desdechado © (29.05.03 14:51)

Согласен.

← →
Жук © (2003-05-29 15:25) [15]

Запрос :
select k.*,n.nk,s.name, a.a_fam,a.a_kolwo,a.a_strana from kniga k left join serii s on k.id_seria=s.id, awtor_knigi(k.id) a,nomer(k.id_inrec) n where k.id_inrec like "1%" order by n.nk

kniga and serii - таблицы, awtor_knigi и nomer - ХП.

План у меня не показывается, но по анализу выполнения видно, что все чтения происходят по индексам, кроме rdb$relation_constraints.

Что бы это значило ?

← →
Johnmen © (2003-05-29 15:44) [16]

>Жук ©

"Ещё одна особенность, точнее на этот раз пожалуй даже глупость, которую периодически пытаются сделать новички. Ну например так:
select * from sp1(t.id) sp, test2 t
То есть в качестве параметра процедуры идёт одно из полей другого соединяемого отношения. Никогда не пройдёт. По той простой причине, что при любой технологии сначала выполняется соединение, а уже потом появляются поля."

Полную статью могу выслать. Где брал ее - не помню...:)

2 Johnmen
и мне статью можно?

> Johnmen © (29.05.03 15:44)

Про глупости интересно, конечно почитать, но всё-таки хочется добить вопрос про таблы и ХП. Я привёл работающий запрос и результаты производительности, в которых показано, что при чтении всех данных были использованы индексы, кроме чтения из системной таблицы rdb$relation_constraints.
Это по-моему опровергает тезис о неиспользовании индексов для селектов из таблиц и ХП одновременно. Нес па ?

Если я не прав, то поправьте.

P.S. Статье буду рад. Мыло в моей анкете.

Жук © (29.05.03 16:03)
Если не ошибаюсь, в твоем запросе awtor_knigi и nomer возвращают по одной записи, так?

Вот если-бы они возвращали с сотню записей, и участвовали в секциях where и order by, тогда-бы ты "прочуствовал" какие там индексы :))

> Danilka © (29.05.03 16:22)

Я и так могу это представить, а желание почуствовать отбило года 2 назад :-)

Здесь несколько другой случай.

>Всем заинтересованным

Нашел я ссылку ! Там много интересного !
http://www.krista.ru/ib/
А ссылку эту давал, по-моему, Alexandr ©

> Жук © (29.05.03 16:03)

Так ты привел план не запроса, а ХП. И то, что в ХП используются индексы вовсе не говорит о том, что при соединении таблицы и выборки из ХП тоже используются индексы. Видишь разницу между выборкой в ХП и соединением в запросе результатов этой выборки с чем-то еще ?

Select из ХП и таблицы в одном запросе Найти похожие ветки