Возврат нескольких полей из хранимой процедуры (Firеbird)

[Антон Ю.Б.]

Товарищ попросил оптимизировать запрос, подобный первому в нижеприведенном списке. Далее последовательно приведены попытки (и их результаты), каждая из которых меня несколько удивила. Никто не подскажет - это документированное поведение (Firebird 2.1)?

select M.ID_, (select X_ from GET_PEL_DATA(M.ID_)), (select Y_ from GET_PEL_DATA(M.ID_)) from MAINTABLE M
422 миллисекунды
select M.ID_, (select X_,Y_ from GET_PEL_DATA(M.ID_)) from MAINTABLE M
(SQL error 104) count of column list and variable list do not match
select M.ID_, G.X_, G.Y_ from MAINTABLE M, GET_PEL_DATA(M.ID_) G;
The cursor identified in the update or delete statement is not positioned on a row. No current record for fetch operation.
select M.ID_, G.X_, G.Y_ from MAINTABLE M left join GET_PEL_DATA(M.ID_) G on 1=1
125 миллисекунд

[Stilet]

это документированное поведение?

Насколько я понимаю вложенные запросы должны дольше выполняться.

[Антон Ю.Б.]

Да я не против, чтобы они дольше выполнялись (хотя разница не в два, а почти в три раза). Если по пунктам, то удивляет, что для 1 оптимизатор не делает результатов, сопоставимых с 4, 2 и 3 удивляют тем, что не работают. 4 удивляет тем, что работает на фоне 2 и 3.

Если не обсуждать оптимизатор, то вопрос в том, что является ли неработоспособность 2 и 3 и работоспособность 4 документированным поведением для таких запросов.

[Антон Ю.Б.]

Добрые люди все разъяснили, попробую изложить. По всем приведенным выше запросам:
1) Процедура считается недетерминированной, принимается, что ее последовательные вызовы с одними параметрами могут возвращать разные результаты. Поэтому оптимизатор принципиально не оптимизирует этот запрос. Посмотреть про это можно здесь http://www.ibase.ru/devinfo/dataaccesspaths.htm (поиск по части слова "недетермин").
2) Вложенный подзапрос из чего угодно (процедура, таблица) должен быть скалярным, два столбца в принципе не допускаются. Об этом есть много где, например у Борри.
3) Связано с пояснениями 1) При расчете плана запроса кардинальность процедуры считается равной 0, поэтому при расчете плана процедура ставится в начало соединения - сначала делается выборка из процедуры, а потом уже из таблицы. Посмотреть можно по прежней ссылке (ищем слова "начало соединения").
4) в этом случае мы принудительно указываем порядок соединения, поэтому все ок.