История изменений
Исправление no-such-file, (текущая версия) :
если используется небуферизированный курсор, то и памяти(озу) расходуется меньше
На стороне питона конечно меньше. Но это пока у тебя хеловорд и одно соединение.
А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?
А вот тут всё плохо. В СУБД не только память может расходоваться, но ещё треды, дескрипторы и т.п. Поэтому только ради памяти так делать не надо (но конечно, ради костылей всё возможно). СУБД хуже масштабируется, чем клиенты. Тут вон в соседней теме обсуждают 16000 соединений…
Получается буферизированный курсор меньше нагружает базу
Да.
зато больше расход нашей ОЗУ
А что ОЗУ БД не наша? Ситуации конечно бывают разные, но как правило ты платишь за то и за то. Не факт что дополнительная нагрузка на БД обойдётся дешевле. Дело ведь ещё в том, что т.к. ты занимаешь соединение долго, то количество соединений тебе понадобится больше (речь не про хеловорды). Даже на клиенте это приведёт к соответствующим расходам.
Исправление no-such-file, :
если используется небуферизированный курсор, то и памяти(озу) расходуется меньше
На стороне питона конечно меньше. Но это пока у тебя хеловорд и одно соединение.
А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?
А вот тут всё плохо. В СУБД не только память может расходоваться, но ещё треды, дескрипторы и т.п. Поэтому только ради памяти так делать не надо (но конечно, ради костылей всё возможно). СУБД хуже масштабируется, чем клиенты. Тут вон в соседней теме обсуждают 16000 соединений…
Получается буферизированный курсор меньше нагружает базу
Да. Но это всё копейки.
зато больше расход нашей ОЗУ
А что ОЗУ БД не наша? Ситуации конечно бывают разные, но как правило ты платишь за то и за то. Не факт что дополнительная нагрузка на БД обойдётся дешевле. Дело ведь ещё в том, что т.к. ты занимаешь соединение долго, то количество соединений тебе понадобится больше (речь не про хеловорды). Даже на клиенте это приведёт к соответствующим расходам.
Исправление no-such-file, :
если используется небуферизированный курсор, то и памяти(озу) расходуется меньше
На стороне питона конечно меньше. Но это пока у тебя хеловорд и одно соединение.
А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?
А вот тут всё плохо. В СУБД не только память может расходоваться, но ещё треды, дескрипторы и т.п. Поэтому только ради памяти так делать не надо (но конечно, ради костылей всё возможно). СУБД хуже масштабируется, чем клиенты. Тут вон в соседней теме обсуждают 16000 соединений…
Получается буферизированный курсор меньше нагружает базу
Да.
зато больше расход нашей ОЗУ
А что ОЗУ БД не наша? Ситуации конечно бывают разные, но как правило ты платишь за то и за то. Не факт что дополнительная нагрузка на БД обойдётся дешевле. Дело ведь ещё в том, что т.к. ты занимаешь соединение долго, то количество соединений тебе понадобится больше (речь не про хеловорды). Даже на клиенте это приведёт к соответствующим расходам.
Исходная версия no-such-file, :
если используется небуферизированный курсор, то и памяти(озу) расходуется меньше
На стороне питона конечно меньше.
А как в таком случае нагрузка на СУБД(ведь данные еще выгружены не все)?
А вот тут всё плохо. В СУБД не только память может расходоваться, но ещё треды, дескрипторы и т.п. Поэтому только ради памяти так делать не надо (но конечно, ради костылей всё возможно). СУБД хуже масштабируется, чем клиенты. Тут вон в соседней теме обсуждают 16000 соединений…
Получается буферизированный курсор меньше нагружает базу
Да.
зато больше расход нашей ОЗУ
А что ОЗУ БД не наша? Ситуации конечно бывают разные, но как правило ты платишь за то и за то. Не факт что дополнительная нагрузка на БД обойдётся дешевле. Дело ведь ещё в том, что т.к. ты занимаешь соединение долго, то количество соединений тебе понадобится больше (речь не про хеловорды). Даже на клиенте это приведёт к соответствующим расходам.