Есть ли возможность для обхода ограничения привязки параметров PostgreSQL 32760?
Другой подход заключается в использовании SimpleXML для синтаксического анализа и DOMDocument для манипуляции / доступа, который вообще обходит проблемы с именами:
$xml = new SimpleXMLElement($r);
$xml = dom_import_simplexml($xml);
$nodelist= $xml->getElementsByTagName('event');
for($i = 0; $i < $nodelist->length; $i++) {
$sessions = $nodelist->item($i)->getElementsByTagName('sessionKey');
echo $sessions->item(0)->nodeValue;
}
1 ответ
Нет, вы не хотите делать это, особенно если вы планируете отправить 8 миллионов идентификаторов. Обход оператора IN или ограничения параметра связывания неэффективен. Рассмотрим следующее:
-
Тысячи параметров связывания приведут к мегабайту SQL. Отправка текста SQL в базу данных займет значительное время. Фактически, для чтения текста SQL может потребоваться больше времени, чем для выполнения запроса согласно ответу Тома на вопрос «Ограничение и преобразование очень длинный IN: ГДЕ x IN (,,, ...)» .
-
Синтаксический анализ SQL будет неэффективным. Не только мегабайты текста SQL требуют времени для чтения, но и с увеличением числа параметров привязки каждый запрос обычно будет иметь различное количество используемых связанных параметров. Это отдельное количество связанных параметров приведет к тому, что каждый запрос будет проанализирован и спланирован отдельно (см. в этой статье, где это объясняется ).
-
В операторе SQL существует жесткое ограничение связанных параметров. Вы только что обнаружили это, 32760.
Для таких типов запросов обычно лучше создать временные таблицы . Создайте новую временную таблицу перед вашим запросом, вставьте в нее все идентификаторы и объедините ее с таблицей сущностей. Это объединение будет эквивалентно условию IN, за исключением того, что текст SQL будет коротким.
Важно понять, откуда эти 8 миллионов идентификаторов загружены. Если вы извлекаете их из базы данных в предыдущем запросе, просто чтобы передать их следующему запросу, вам, скорее всего, потребуется написать хранимую процедуру. Возможно, в вашем текущем подходе есть недостаток, JPA не всегда является подходящим инструментом для работы.