Katherine Marsden <[email protected]> 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
