Есть ли возможность обойти ограничение параметров привязки PostgreSQL 32760?
В моем репозитории есть метод JPA, который пытается найти объекты с предложением where. Проблема в том, что у меня огромный набор данных, и когда я пытаюсь отправить более 32 тысяч элементов в предложении списка, я получаю ошибку. Я обнаружил, что это ограничение драйвера PostgreSQL, но я не могу найти обходного пути.
Я попробовал запрос Pageable, но сложно отправить только 30k на 8 миллионов записей. Есть ли возможность отправить более 30 тыс. Объектов из пункта where в моем списке?
List<Object> findAllByIdIn(List<Long> ids)
Ответы 1
Нет, вы не хотите этого делать, особенно если вы планируете отправить 8 миллионов идентификаторов. Обход оператора IN или ограничения параметра привязки неэффективен. Учтите следующее:
Тысячи параметров привязки приведут к мегабайтам SQL. Отправка текста SQL в базу данных займет значительное время. Фактически базе данных может потребоваться больше времени для чтения текста SQL, чем для выполнения запроса согласно Ответ Тома на вопрос "Ограничение и преобразование очень длинного списка IN: WHERE x IN (,,, ...)".
Разбор SQL будет неэффективным. Не только мегабайты текста SQL требуют времени для чтения, но и с увеличением количества параметров привязки каждый запрос обычно имеет определенное количество используемых параметров привязки. Этот счетчик различных связанных параметров приведет к тому, что каждый запрос будет анализироваться и планироваться отдельно (см. эта статья, которая объясняет это).
В операторе SQL существует жесткое ограничение на количество связанных параметров. Вы только что обнаружили это, 32760.
Для таких запросов обычно лучше создать временные таблицы. Перед запросом создайте новую временную таблицу, вставьте в нее все идентификаторы и соедините ее с таблицей сущностей. Это соединение будет эквивалентно условию IN, за исключением того, что текст SQL будет коротким.
Важно понимать, откуда загружены эти 8 миллионов идентификаторов. Если вы извлекаете их из базы данных в предыдущем запросе, просто чтобы передать их в следующий запрос, вы, скорее всего, захотите написать хранимую процедуру. Возможно, в вашем текущем подходе есть изъян, JPA не всегда является подходящим инструментом для работы.
Вставьте все идентификаторы во временную таблицу при использовании
where x.ID in ( select ID from TempIDs )