слишком много вас таких, желающий вытащить "десяток мегабайт". Никакой памяти не напасёшся.
А потом, например, при SORT создается временный файл, который ОС пытается разместить в памяти полностью.
А ты его затем утаскиваешь.
Впрочем, заканчивается это всё точно так же - приходит 10-20 таких клиентов, каждому подай отчет 2-5 гиг, в результате память кончается, и всё это тащится на клиента с диска. А потом жалуются.И к чему это? Сортировка должна быть произведена полностью в любом случае - все я записи профетчил или нет.
Даже если бы это было не так - не вижу смысла делать многомегабайтные запросы и потом, не фетча записи, закрывать запрос. Это странные клиенты. Хотя всякая логика бывает, конечно.

Не вижу, как это усложняет задачу кроме возможности запроса
"верни следующую запись"
добавить возможность запроса
"верни следующие N записей или сколько осталось, если их меньше N".

Или ты на память намекаешь? Если да - то это полностью на совести прикладных программистов будет, ясное дело.
Они могут как существенно снизить время получения данных, так и переполнить память сервера, что увеличит это время.

hvlad,

Вот, к примеру, есть отчет, который возвращается запросом, результат которого будет 10000 записей 10Мб.

Это на 100 клиентов - 1Gb всего на буффер для этого. При условии, что все одновременно захотят.

Вот у меня клиент есть ~150 точек, большинство из которых - на спутнике (и ничего другого нет лучшего).
Скорость > 10Мбит, но пинг - 9 секунд.

Получить такой резалтсет в таких условиях можно было бы за 20 секунд. И серверу было бы лучше - отдал сразу всё и забыл.
А сейчас за такую задачу даже браться нет смысла - не дождутся, приходится придумывать другие архитектурные решения.

Так и я об этом.
Потому надо давать больше свободы прикладным программистам - они знают (могут знать), как в их случае может быть лучше.

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

Даже если и так - это было бы жизнеспособно.

Я не в курсе, если это возможно - хорошо, это похоже на решение проблемы долгого пинга.

Почему? На сервере - именно гигабитная.

Да, даже так очень жизнеспособно, ибо никогда не бывает, чтобы именно этот отчет бухгалтеры магазинов запустили именно одновременно.
А даже если 10 одновременно - это всего лишь 100 секунд - это реальное время.
Сколько времени займет поочерёдный фетч 10к записей - я даже считать не хочу.

Благодарю, почитал.
Там вроде лимит в 32 кб.
Легко посчитать во мя для моего примера: 10000/32 = 300. 3 тысячи секунд. Это - НЕ жизнеспособно.
Но всё равно спасибо, это может ускорить некоторые кейсы в несколько раз.

сервер в вакууме? Ты о чем вообще? Допустим, на сервере сеть гигабитная, а у клиента модем gprs 3g. Дальше что?Сервер что, со всеми клиентами работает по скорости самого медленного (тонкого) клиента?

Или по очереди? Я не понимаю, на что вы намекаете.

Я понимаю так, грубо говоря: если сервер гигабитный, и у него 10 клиентов 100-мегабитных, то сервер может в секунду посылать по 100 мегабит каждому клиенту, а вот если клиентов 11 - то уже меньше.
Возможно, я заблуждаюсь.

Кого еще, если у него 10 клиентов? Именно их он и должен обслуживать. Ну, еще, может, что-то важное делать с базой, накладные расходы... Я написал: грубо говоря.

Странно это слышать. Я не знаю особенностей внутренностей сервера, но, странно... Как бы то ни было.



Я и не говорю, что на каждую запись отдельный пакет. Но на размер пакета 32кб уже делил - всё-равно ужасно на долгом пинге.