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

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

Firebird, group by и временные файлы

Покопался в исходниках Firebird (2.5.2) на тему размеров временных файлов.
В итоге, там картина примерно такая:
* Запрос с условием и group by, входной датасет - десятки миллионов записей, результатирующий датасет - 150000 записей, размер записи порядка 150 байт (varchar расширены до максимального размера).
* Для выполнения запроса, подпадающие под условие записи (десятки миллионов) пишутся в сортировщик, затем досортировываются и выгребаются из него в правильном порядке с вычислением аггрегатов.
* Сортировщик реализован поверх временного хранилища данных, которое в свою очередь представляет последовательность блоков размером 1 мб, поначалу находящихся в памяти, а по мере превышения порога (8 МБ по умолчанию для классик-сервера) - записываемых во временные файлы. По виду это все крайне напоминает самодельную реализацию pagefile.
* Временные файлы расширяются кусками по 64 мб, с записью 262144 байтных буферов с нулями в эти куски.

Что здесь очень мне не нравится - это то, что обмен с временными файлами в принципе не выровнен по границам блоков диска, а является кратным размеру записи. Вот, например, из отладочного лога TempSpace::write: 2898976500 1048500

Второе - по-моему, конкретно для данного случая положить готовый результат group by в памяти в виде какого-нибудь дерева поиска и считать аггрегаты на ходу в него было бы гораздо эффективнее, чем долбится в i/o. Фактически мы при запросе читаем всю таблицу, пишем часть прочитанного в временный файл, потом сортируем, потом читаем обратно.
Но, возможно, нету эффективных способов отличить небольшой размер результата от большого размера, который эффективнее делать через сортировку.