ну так я и предложил вариант. если можно читать таблицу частями, то можно попробовать секционирование

И ещё на тему "вокруг да около", мне эти советы про партиционирование почему-то напоминают (парафразируя известное высказывание):
"У нас была проблема с производительностью, и мы решили попробовать партиционирование. Теперь у нас две проблемы!"

я же не виноват что у вас какие-то комплексы насчет партиций :)

Не у меня. Тот, кто ожидает повышения производительности от него по умолчанию, верит в "волшебную пыль".
Т.е. это распространённый глупый миф, и не более того.

я не знаю в какой предметной области вы работаете, но в телекоме без них никак увы.

У меня тут много вопросов возникает.
1) вам нагрузка не нравится, потому что она идёт скачками (в период выполнения тяжёлого запроса) и влияет на выполнение других запросов? Если так, то высасывать данные пачками по 10-100к - нормальный вариант. Можно хоть thread.sleep делать между итерациями. Но нужно придумать, как определять, какие данные уже были выбраны, чтоб эта схема оказалась не *N(батчей) по ресурсоемкости от текущего варианта.
2) эти 14 миллионов записей каждый раз разные? Или постоянно одни и те же данные выбираются, потому что нет инкрементальности? Если так, то добавление инкрементальности в схему/запрос - скорее всего лучшее решение

я правильно же понимаю, что под пачками имеется ввиду limit?
но да, при таких скачках у нас "тупят" другие запросы.

и что есть инкрементальность, простите за вопрос?)

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

При чём тут предметная область-то?! "В военное время значение синуса может достигать четырёх", что ли? ;)

Да, есть конкретные задачи / данные, где партиционирование [сильно] помогает с производительностью, но по сравнению с прочими — это маргинальный случай, понимаете? Т.е. Вам просто так "везёт", и нет объективных причин распространять это на весь мир / все возможные нагрузки, вот в чём суть.

Limit в каком-то виде, да. Про инкреметальность - насколько я понял ваш вопрос, клиент регулярно высасывает 14 миллионов записей. Вопрос возникает, что это за записи - все 14 миллионов каждый раз новые, или это одни те же записи с небольшими изменениями, которые каждый раз целиком выбираются из базы и где-то ниже по пайплайну diff'аются с предыдущей выборкой

И на диск и на проц сервера БД так же влияет, так как положить все данные в память требуется их прочитать с диска сначала. Курсоры этого не наделают а читают последовательно при Next.

по идее, данные могут меняться, не все, частями и не всегда

Если клиент очень быстро обрабатывает (типа просто шлёт кафку все сразу), то кажется все равно могут быть проблемы. Но у меня мало опыта с курсорами, может они прям божественно работают для такого кейса)

Использовать синхронный канал или с буфером по 10000 записей.

Ну вот, идея про инкреметальность - добавить признак, по которому можно понять, изменилась запись с последнего запроса или нет. Можно заюзать sequence, например

А зачем это делать в БД? Что вам мешает в приложении это делать?

Так не интересно:)

ещё раз рискну спросить, можно ли чем-то заменить множественное обновление временной таблицы. Пробовал в цикле, чуть дольше было
 UPDATE temp ts
 SET status_id = A.status_id
 FROM
   ( SELECT ..... status_id FROM tickets WHERE ....) AS A
 WHERE
   ...
   AND ...
   AND ...;

Что подразумевается под множественным обновлением?

куча строк обновляется в одном вызове