PostgreSQL и JDBC выжимаем все соки. Владимир Ситников

[erogov]

В 12-й версии сделали-таки параметр plan_cache_mode для управления generic-планами.

[mike0007]

… открываем resultSet и читаем оттуда данные понемногу… Здесь, как обычно, самый неожиданный вариант оказывается правильным. И если вы вдруг выключите autoCommit, то оно поможет. Почему так? Науке об этом неизвестно.

Всё очень просто — читать можем так долго а за это время что-то может и измениться, поэтому открываем транзакцию (MVCC). Вроде логично.

[vladimirsitnikov]

На самом деле, логики никакой нет. Это просто особенность реализации PostgreSQL, которая заключается в том, что при завершении транзакции все курсоры превращаются в тыкву

Например, в Oracle DB курсоры без проблем переживают операцию commit и продолжают возвращать согласованные данные. Можно открыть курсор, сделать commit (или несколько) и без проблем продолжать выборку из курсора. Разумеется, у долгих курсоров есть шанс наткнуться на ORA-01555 snapshot too old, но это другая история.

Разработчики PostgreSQL почему-то посчитали, что, если транзакцию закрываем, то и курсоры нужно обязательно закрыть. При этом, фиксация транзакций в параллельных потоках никак не влияет.

Типичный подход в Oracle мире для batch обработки: открываем курсор, выбираем 10'000 записей. Обрабатываем, меняем данные, выполняем commit. Выбираем следующие 10'000 (операцией fetch bulk collect into… limit 10000) и так далее. Это позволяет не выполнять выборку каждый раз с нуля, и «выбирающий» курсор не протухает. В PostgreSQL такой подход не работает.