Re: lots of values for IN() clause
| От | Gurjeet Singh |
|---|---|
| Тема | Re: lots of values for IN() clause |
| Дата | |
| Msg-id | 65937bea0611020833h373e0300gcaa525fd7bb17060@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: lots of values for IN() clause (Alvaro Herrera <alvherre@commandprompt.com>) |
| Ответы |
Re: lots of values for IN() clause
|
| Список | pgsql-general |
But I do not understand why the IN list has to make so many recursive calls???
I know if it was possible, it'd have been done already... but can 'making it iterative' (whatever 'it' stands for) be reconsidered?
I know if it was possible, it'd have been done already... but can 'making it iterative' (whatever 'it' stands for) be reconsidered?
--
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
On 11/2/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
gurjeet[.singh]@EnterpriseDB.com
singh.gurjeet@{ gmail | hotmail | yahoo }.com
On 11/2/06, Alvaro Herrera <alvherre@commandprompt.com> wrote:
I notice it crashes with max_stack_depth set to 8173, but correctly
detects the error with max_stack_depth set to 8172. The doc suggests a
safety margin of "a megabyte or so", so I think we are conforming to our
docs here.
Tom recently added a check for getrlimit(RLIMIT_STACK), but I don't know
if that considered the "megabyte or so". *peeks the code* Yeah,
there's a 512 kb "daylight", but there's also an absolute maximum of
2MB.
В списке pgsql-general по дате отправления: