db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Heap and stack size for Derby server
Date Fri, 03 Nov 2006 17:56:47 GMT
I would report this as a separate issue and possibly link it to
DERBY-47, that way anyone who fixes it can also run your test case
to make sure it is also addressed.  It may be fixed by DERBY-47
but may not.  Including a stack trace with the simple test program will
help a lot in understanding where the issue is (ie. did the stack 
overflow while compiling the 5000 term IN list, or did it overflow 
during execution of the generated queryplan).

In 10.2 a lot of work was done by Dan on reducing the resources during
compile time of queries that had a lot of terms.  Without the stack
trace it is hard to guess if this is a compile or execution issue.

Do note that currently in derby IN list queries are probably not going
to perform as you expect.  They do not do a probe using the index for
each term.  There are a few workarounds, which require rewriting the
query.

Bryan Pendleton wrote:
>> My problems came from a simple query containing an IN clause with 5000 
>> items in it. I went over this easily by increasing the stack size 
>> limit to 1024 KB.
> 
> 
> Thanks Robert! That definitely sounds like DERBY-47. If you have the time,
> it'd be great to have some help in working on improving this part of Derby.
> 
> I'm glad you were able to find a workaround to the problem.
> 
>> The question I'm asking is if there are some best practicing in sizing 
>> the heap and stack for the Derby process based on the query 
>> complexities, number of database objects and estimated amount of data.
> 
> 
> I think that one reason you haven't had a lot of response on this is that
> many people aren't experiencing a lot of problems in this area. In my
> case, for example, my Derby application has been running quite happily,
> 24/7, for several years, in the default heap and stack.
> 
> thanks,
> 
> bryan
> 
> 
> 


Mime
View raw message