FavnСчитайте, что я тоже задал вопрос - почему DB2, делая "двойную работу" (запись в лог и БД, да еще на одном диске), оказалась заметно быстрее?А если в замер скорости включить ещё и время коммита и чекпойнта (последнее для DB2) ?
Насчёт чекпойнта могу ошибаться - речь о процессе сброса в БД грязных страниц, уже записанных в лог.

Далее, насколько я помню, в DB2 у табличных пространств есть параметр, управляющий кешированием ОС. Чему он был равен ?

И как у DB2 происходит рост файла БД ? По мере надобности, или БД уже имеет некий начальный размер при её создании ?

FavnКак учесть сброс логов именно для данного запроса - не знаю. Можно деактивировать БД, но это нечестно - там выполняется куча другой работы.Должен быть оператор вроде CHECKPOINT, нет ? Или опция коммита, но это уже фантазии :)

FavnНа самом деле, запросы прогонял дважды: insert-delete-insert, т.е. 2-й раз tablespace уже был нужного размера. Время отличалось незначительно.И для Firebird дважды ?
А если для Firebird попробовать (чтобы точно исключить влияние расширения файла)
insert, commit,
recreate table, commit,
insert, commit,

?

Victor Metelitsahvlad
Глубина рекурсии ограничена значением 1024, поэтому такой запрос

Может, "рекурсии ограничена значением 1024" на самом деле относится только к вызову SP из себя или вроде этого? У SP\триггеров другой лимит.

Victor MetelitsaПроверьте, пожалуйста. Ну, если учесть, что я его и делал... :)

Victor MetelitsaПросто странно такое читать, ибо у этого запроса только форма записи рекурсивная, а реально это цикл, и нет никаких причин его так ограничивать.Понятно, что стек оно не есть. Но каждый "рекурсивный" вызов всё-таки потребляет память, и ограничивать это дело нужно.

Другой вопрос, что мы в своё время слишком перестраховались в этом месте. Ну и лимит можно сделать настраиваемым.
Не хотелось нестандартные расширения SQL вводить.

А причины ограничивать (кроме расхода памяти) всё-таки есть. Из-за ошибки в запросе такой цикл легко может стать бесконечным.
Лимит позволяет это выяснить гораздо раньше, чем исчерпается память.

Victor Metelitsahvlad
Victor MetelitsaПросто странно такое читать, ибо у этого запроса только форма записи рекурсивная, а реально это цикл, и нет никаких причин его так ограничивать.Понятно, что стек оно не есть. Но каждый "рекурсивный" вызов всё-таки потребляет память, и ограничивать это дело нужно.

Другой вопрос, что мы в своё время слишком перестраховались в этом месте. Ну и лимит можно сделать настраиваемым.
Не хотелось нестандартные расширения SQL вводить.

А причины ограничивать (кроме расхода памяти) всё-таки есть. Из-за ошибки в запросе такой цикл легко может стать бесконечным.
Лимит позволяет это выяснить гораздо раньше, чем исчерпается память.

Как же DB2 обходится без жёсткого лимита? Причём это 10 лет назад уже было реализовано? А как DB2 выполнит запрос с бесконечной рекурсией и за какое время ? Сколько ресурсов на это будет потрачено ? И какой в этом глубокий смысл ?

Кстати, в MSSQL лимит тоже есть. Правда он может быть указан в самом запросе. Но MS не привыкать ложить на стандарт. И жёсткий лимит там тоже имеется, правда выше, чем в Firebird.

Victor MetelitsaИ куда вы расходуете память? Я её ем :)
В памяти живут текущие записи внутренних узлов рекурсивного дерева, их необходимо помнить, так как с их помощью выполняются запросы соответствующих дочерних узлов. В этом смысле - стек вызовов есть ближайшая аналогия.

Victor Metelitsa"Рекурсивный" вызов похож на математическую индукцию. "Шаг 0" - это то, что выше union all. Ниже union all рассказывается, как из множества для шага N получается множество для шага N+1 (и выполнение прекращается, когда оно пусто). На вид всё просто - временная таблица (прозрачная для пользователя; такая, какая может возникнуть для group by или order by), которая может быть в памяти или выложена на диск, когда памяти не хватает и два указателя (начало и конец шага N).На вид всегда всё просто :)
Firebird отличается от DB2 ещё и тем, что этот самый вид виден всем и доступен для изучения и модификации.
Так что жду ваш более совершенный вариант выполнения рекурсивных запросов для Firebird ;)

На самом деле нет проблем сбрасывать вышеупомянутые записи на диск, при необходимости.
Вопрос в наличии этой самой необходимости. Как только она реально возникнет - будет и реализация.