pastor, а не будет ли минусом в производительности, что GTT работает через файлы, а обычные таблицы через ОЗУ?

Почему чушь то?

pastorGTT файлы в точности такие же как и файлы БД, только они
1. временные, в т.ч. с точки зрения ОС
2. лежат в каталоге для временных файлов

во всем остальном они работают через тот же самый нерезиновый страничный кэш, с теми же самыми стратегиями использования памяти.
Всем спасибо за советы, решено отказаться от GTT т.к. явных преимуществ в производительности не видно, но огромный минус это отладка sql-запросов с использованием GTT особенно когда GTT заполняется на клиенте

Вместо GTT решено использовать свою временную таблицу (стандартную)

Симонов Денисfedorov2012,

решил изобрести велосипед. Ждём вопросов почему база распухла и откуда берутся тормоза.
кстати до этого база работала на FB 2.0 все ок - не распухла (tmp_table всегода оказывалась пустой) да и распухать неоткуда т.к. моя временная таблица используется на select без коммита транзакции, поэтому даже если возникнет дисконект все равно мусора не возникнет

m7m, естественно все что здесь мною пишется это чисто мои мысли

Ivan_PisarevskyКак же не видно, если при наличии ОЗУ ОСь не будет их материализовать на диске, а для стационарных таблиц это будет сделано обязательно
1. GTT работает через временные файлы
2. FB не дура, сбрасывать данные она будет в большинстве случаев, если идет комиит транзакции или ОЗУ заканчивается
3. Сделан емкий тест - разницы в производительности не замечено.


Ivan_Pisarevskyна время отладки делается стандартная таблица в тестовой БД, после отладки в рабочую БД идет ГТТ.
ага, а если это стек вызовом хранимых процедур ссылающиеся на tmp_table - все перекомпилировать на новую таблицу стандартную tmp_table2 - ну и зачем такой огород - ради чего, если нет очевидных плюсов GTT

Симонов Денисчто такое мусор по твоему? Я тебе про версии записей говорил, а не про ненужные записи.
версий записей не возникает т.к.
1) транзакция не коммититься
2) при первом же select'e tmp_table все подчищается
3) select вызывается сразу же после вставки промежуточных id'шников в tmp_table т.к.после её заполнения она сразу же используется в select'ах

roadsterfedorov2012моя временная таблица используется на select без коммита транзакциив сессии идёт вставка, в твою таблицу, а затем селект? и это делается в одной транзакции?
Да! Временная таблица нужна для оптимизации скорости выборки когда join'иться куча таблиц - например, пользователь отмечает нужные записи галочкой и формирует отчет - выборка сделается только по этим записям

Симонов Денисfedorov2012,
А что же делается ROLLBACK?

естественно, данные мне нужны для выборки (например сформировать отчет0

Симонов Денистак у тебя же фильтрация идёт по сессиям. Значит почиститься она теоретически может только в своей сессии и то при следующем выполнении.

работа каждой сессии завершается вызовом select'a запроса в котором и участвует наш tmp_table.

Симонов Дениссборка мусора может начаться только после завершения текущей транзакции. Т.е. твой select будет делать сборку мусора только в новой транзакции
Даже если и так, это операция мгновенная на тех объемах (10-500 записей) которые вставляются в tmp_table. Но повторюсь сборка мусора выполниться в этом же select'e, схема такая:
1. myTran //create and start
2. Fill tmp_table
3. select * from tmp_table tmp, mytable1 t1, mytable2 t2...
where t1.id=tmp.tmp_id and t2.id2=t1.id2 and...

hvladfedorov20123. Сделан емкий тест - разницы в производительности не замечено.Ты DELETE не забыл убрать из своего ёмкого теста ?
не забыл и delete не обязателен т.к. commit'a нет

Симонов ДенисВот если бы у тебя Fill tmp_table выполнялся в одной транзакции. А select в другой тогда выполнялась бы. Но для этого необходимо чтобы транзакция которая для Fill tmp_table завершилась. А поскольку у тебя она завершается откатом данные ты не увидишь.
Все нормально работает, мусор не накапливается - делаю простой пример
1. стартуем транзакцию
2. заполняем tmp_table
3. выполняем select sql-запрос с участием tmp_table для формирования отчета.
4. закрываем транзакцию с откатом.
5. Смотрим статистику базы через IBExpert левых версий 0.
ч.т.д.