[
https://issues.apache.org/jira/browse/DERBY-6096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593464#comment-13593464
]
Knut Anders Hatlen commented on DERBY-6096:
-------------------------------------------
You may have better luck with smaller LOBs. LONG_CLOB_LENGTH is 18000000, which
means the SQLClob objects inserted into BackingStoreHashtable aren't
materialized and don't take up that much space. Using a larger number of
smaller LOBs (so small that they don't overflow to another page) should
increase the memory footprint, as those LOBs will come out of store fully
materialized.
> DataTypeDescriptor.estimatedMemoryUsage() has no case for BLOB or CLOB so
> would underestimate memory usage for those types at zero
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6096
> URL: https://issues.apache.org/jira/browse/DERBY-6096
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.3.0,
> 10.6.2.1, 10.7.1.1, 10.9.1.0, 10.10.0.0, 10.8.3.0
> Reporter: Kathey Marsden
>
> In discussion on derby-dev regarding how much memory is used for hash joins,
> Knut noted:
> I haven't verified, but I think HashJoinStrategy uses
> DataTypeDescriptor.estimatedMemoryUsage() to estimate how much memory
> the hash table will consume. That method has no case for BLOB or CLOB,
> so it looks as if it will return zero for LOB columns. If that's so, it
> will definitely overestimate how many rows fits in maxMemoryPerTable
> kilobytes if the rows contain LOBs.
> DataTypeDescriptor.estimatedMemoryUsage() should be updated to include BLOB
> and CLOB and we should try verify if this theory is correct with a
> reproduction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
