[
https://issues.apache.org/jira/browse/DERBY-5698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13273070#comment-13273070
]
Kristian Waagan commented on DERBY-5698:
----------------------------------------
Derby uses a header to store length information for LOBs. If this header can't
be filled in when the LOB is inserted, which will be the case if the LOB is
inserted without specifying the length up front and the LOB is larger than a
single page (typically 32 KB, but may be smaller too), Derby has no mechanism
to update the header without rewriting the whole LOB at a later time.
The insert performance will be unaffected ([1]). You'll see impaired
performance if you start asking for the length of these LOBs, as Derby has to
fetch and decode the whole value to find the length.
If you're just reading data, say, with a stream, performance is unaffected.
Assuming you inserted 101 LOBs without specifying their lengths, 100 of them
being 2 GB big and one only 10 bytes, you'd be in a world of hurt with the
following query:
select min(length(myLOBs)) from mytable
I think this can be fixed, but it will require some non-trivial work in the
store.
[1] For recent versions, there were some edge-case issues with older versions
using the client driver.
> Document performance issue with 2-arg versions of setXXXStream methods for
> LOBs
> -------------------------------------------------------------------------------
>
> Key: DERBY-5698
> URL: https://issues.apache.org/jira/browse/DERBY-5698
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.8.2.2
> Reporter: Kim Haase
> Assignee: Kim Haase
> Attachments: DERBY-5698.diff, DERBY-5698.stat, DERBY-5698.zip
>
>
> The PreparedStatement.setAsciiStream and other methods have a 3-arg form that
> includes the length of the stream and a 2-arg form that does not. If the
> 2-arg form is used, Derby has to calculate the length every time the method
> is called. With LOBs, especially large ones, this can cause a major
> performance impact, especially if the method is called repeatedly. This
> should be documented where appropriate.
> Kristian, please feel free to correct or amplify anything I've said here.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
