Нихт фертшейн

[metaclass]

В результате запроса 150000 записей.
Размер временного файла для результата запроса, созданного Firebird - около 2Гб. Этот же результат, экспортированный в CSV - 5 мб.
13 килобайт на запись что ли, во временном файле. И фетч медленный как капец.
Надо, что-ли, во внутренности этого файла заглянуть будет как-нибудь, что ж там такое.
PS: при увеличении количества записей в запросе в 10 раз размер файла становится 2.2 гб. Сплошной wtf.
PPS: да это вообще абсурд - оно пишет во временный файл в три раза больше, чем читает с диска.

Comments

[artureg.livejournal.com]

выкинь Firebird :)

[denisioru.livejournal.com]

Предрекаю padded строковые данные до своей максимальной длины. А зачем временный файл на 5 МБ данных?

[falcrum.livejournal.com]

Загляни. Разница на три порядка как-то внушает...

[vp.livejournal.com]

какая-то натуральная чернь :(

[mipa.livejournal.com]

Этот файл создается как временный скорее всего (FILE_ATTRIBUTE_TEMPORARY), т.е. никакого IO с диском нет пока хватает памяти.

[fraks-nsk.livejournal.com]

Про файлы сортировки можно поискать на sql.ru или спросить у hvlad там же.
На сколько я в курсе в файлах сортировки пишутся все поля во всю декларируемую ширину и все поля участвующие в select.
Или попробовать переписать запрос что бы сортировка была либо раньше линковки большинства полей либо после всех условий ограничения.

[fraks-nsk.livejournal.com]

Йоу, я понял.
У тебя сортировка идет натуралом а условия ограничения накладываются после нее.
Тот результат который ты в CSV пишешь и то что во временном файле - это совсем разные вещи.
Кстати во временном файле там не CSV там скорее на DBF похоже, по крайней мере в том что касается строковых полей.

[fraks-nsk.livejournal.com]

Запрос, DDL и план покажи.

[anonim-legion.livejournal.com]

Предлагаю бредовое решение - временные файлы на in-memory диске, со включенным сжатием.