![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Нихт фертшейн
В результате запроса 150000 записей.
Размер временного файла для результата запроса, созданного Firebird - около 2Гб. Этот же результат, экспортированный в CSV - 5 мб.
13 килобайт на запись что ли, во временном файле. И фетч медленный как капец.
Надо, что-ли, во внутренности этого файла заглянуть будет как-нибудь, что ж там такое.
PS: при увеличении количества записей в запросе в 10 раз размер файла становится 2.2 гб. Сплошной wtf.
PPS: да это вообще абсурд - оно пишет во временный файл в три раза больше, чем читает с диска.
Размер временного файла для результата запроса, созданного Firebird - около 2Гб. Этот же результат, экспортированный в CSV - 5 мб.
13 килобайт на запись что ли, во временном файле. И фетч медленный как капец.
Надо, что-ли, во внутренности этого файла заглянуть будет как-нибудь, что ж там такое.
PS: при увеличении количества записей в запросе в 10 раз размер файла становится 2.2 гб. Сплошной wtf.
PPS: да это вообще абсурд - оно пишет во временный файл в три раза больше, чем читает с диска.
no subject
no subject
А вот новые надо переселять.
no subject
no subject
28 мб - это в памяти в rbtree держать надо, а не в i/o в 2гб файл долбится.
no subject
no subject
no subject
есть флаг DELETE_ON_EXIT для временных, может хендлаться по-всякому
может файловые права и не помогут -- тогда только хардкор
no subject
no subject
Неизвестно, что будет быстрее - то ли так, то ли поставить на виртуалку и выключить ее до фетча записей.
no subject
no subject
no subject
no subject
При наличии памяти проще было бы отдать ее самому FB, чтобы он вообще на диск не лез.
no subject
На сколько я в курсе в файлах сортировки пишутся все поля во всю декларируемую ширину и все поля участвующие в select.
Или попробовать переписать запрос что бы сортировка была либо раньше линковки большинства полей либо после всех условий ограничения.
no subject
no subject
no subject
У тебя сортировка идет натуралом а условия ограничения накладываются после нее.
Тот результат который ты в CSV пишешь и то что во временном файле - это совсем разные вещи.
Кстати во временном файле там не CSV там скорее на DBF похоже, по крайней мере в том что касается строковых полей.
no subject
Во временном файле там временные данные сортировщика, причем сортируются данные прошедшие через условие.
no subject
no subject
no subject
no subject
Где вы возьмете по 2гб на каждого из 50 пользователей?
no subject
no subject
no subject
Не встречался еще с такой ситуацией когда ничего кроме как пилить сервер сделать нельзя.
no subject
За данные мне безопасники клиента оторвут голову :)
no subject
Алгоритм расчетов - это и есть запрос.
В каких-то случаях его можно размазать и на клиента но если у тебя исходные данные на сервере - то лучше их там и обрабатывать а не таскать по сетке.
no subject
В общем, там все равно надо переделывать, т.к. количество данных линейно растет со временем, поэтому нужно заменить на хранимые агрегаты и отслеживание изменений по ним.
Конкретно с этим запросом на данный момент ничего не сделаешь - он выгребает и сортирует 2 гб данных из двух таблиц соединенных джоином.
no subject