db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: How Much Memory for hash joins
Date Mon, 04 Mar 2013 13:13:44 GMT
Katherine Marsden <kmarsdenderby@sbcglobal.net> writes:

> On 2/28/2013 9:11 AM, Mike Matrigali wrote:
>> In BackingStoreHashTableFromScan I see.
>>>
>>>        this.max_inmemory_rowcnt = max_inmemory_rowcnt;
>>>          if( max_inmemory_rowcnt > 0)
>>>              max_inmemory_size = Long.MAX_VALUE;
>>>          else
>>>              max_inmemory_size = Runtime.getRuntime().totalMemory()/100;
>>>
>
>
> I have been reading the comments and trying to make sense of the logic
> and understand all that is happening with max_inmemory_size. I don't
> have a test case that goes through the else part of the condition
> above.
>
> One thing I did notice is that Runtime.getRuntime().totalMemory()
> returns really different things if -Xms is set large, for example with
> nothing else going on with  -Xms1048m -Xmx1048m I get:
>
> Total Memory:1098907648 Free Memory:1088915600
>
> With just    -Xmx1048m
> Total Memory:4194304 Free Memory:2750304
>
> Two questions
> 1) Might hash joins use an unexpectedly large amount of memory if -Xms
> is set large?  I know at the user site where this was being set, they
> were setting -Xms in the hopes of optimizing memory usage but I wonder
> if it actually increased the amount of memory used by hash joins.

I think hash scans pass in a maximum row count to the
BackingStoreHashTable, so the totalMemory() calculation won't be used by
hash joins. The only use of the totalMemory() calculation I'm aware of,
is for scrollable result sets.

> 2) Is there a test case that goes through the else clause above that I
> could use for my experimentation?

Executing this command in ij exercises the else clause:

ij> get scroll insensitive cursor c as 'select * from sys.systables';

-- 
Knut Anders

Mime
View raw message