Thanks for all of your replies, but I'm not saying that we have a bug
here. It's just that for large IN clauses there are many levels of
recursive calls in the server.
This reminded me of the other runtime memory limit, the heap. And so I
asked for some best practices on sizing these.
Regards,
Robert
Army wrote:
Bryan Pendleton wrote:
I don't think this is DERBY-47. DERBY-47 is the issue that the plan
generated by an IN query is inefficient.
This issue is that a query with a large number of IN parameters
fails to compile due to a stack overflow error.
Do we know for sure that it's a compile time error and not an
execution error? I haven't been following this that closely so sorry
if that's been stated somewhere.
Is this issue already known, then? Or would it be helpful for Robert to
file a new Jira issue to track it?
Sort of kind of maybe seems similar to DERBY-634 (don't let the title
of that issue throw you). But of course, DERBY-634 is marked as
resolved in 10.2.1.6, which is the version Robert is using. So that's
not *the* issue...but maybe it's related?
Army
