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

[metaclass]

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

Comments

[fraks-nsk.livejournal.com]

По идее надо просто переписать запрос что бы группировка была по индексу или что бы при сортировке натуралом было минимум полей, остальные приджойнить потом.

[metaclass.livejournal.com]

Не, тут конкретно все поля нужны, и индекса нет (входные данные - несколько таблиц), без вариантов.

[fraks-nsk.livejournal.com]

Скинь мне на мыло DDL и запрос, у и в идеале - чуток данных на которых можно опираться.
Не встречался еще с такой ситуацией когда ничего кроме как пилить сервер сделать нельзя.

[metaclass.livejournal.com]

Сервер пилить не надо, надо алгоритм расчетов модифицировать.
За данные мне безопасники клиента оторвут голову :)

[fraks-nsk.livejournal.com]

Реальных данных мне не надо, просто такие что бы были похожи и можно было с тобой получаемые цифры обсуждать.

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

[metaclass.livejournal.com]

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

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

[fraks-nsk.livejournal.com]

мыло fraks собака sibverk точка ru