Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .."
В списке pgsql-sql по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .." |
| Дата | |
| Msg-id | 29030.1053113122@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Efficiency Issue with "SELECT IN (..)" and "SELECT .. OR .." (Mike Winter <mike.winter@frontlogic.com>) |
| Список | pgsql-sql |
Mike Winter <mike.winter@frontlogic.com> writes: > If the "IN (1, 2, 3, 6, ..., n)" clause is big enough, the > database will actually throw an error saying "Recursive Depth > Exceeded" or something similar and not complete the query. Would it perhaps be saying "out of free buffers: time to abort!" ? If so, you're probably running into this bug, which was introduced (by me :-() in 7.3: http://archives.postgresql.org/pgsql-hackers/2003-03/msg00939.php There is a fix in place for 7.3.3. > It looks to me like the query parser is recursively calling > an index scan for each row in the 'IN' clause rather than just > doing one index scan that it seems it should be. It is performing one index search per target value, yes, but not recursively. That's what it's supposed to do. regards, tom lane
В списке pgsql-sql по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера