[jira] Commented: (DERBY-2698) caching collation elements in WorkHorseForCollatorDatatypes may improve performance.

["Daniel John Debrunner (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-2698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12499321 ] 

Daniel John Debrunner commented on DERBY-2698:
----------------------------------------------

I'm not convinced this approach is the best. The conversion of the complete value as collation values in an int array is expensive in the first place, caching it may be attacking the wrong problem. DERBY-2699 is driving at not converting the full value up front, it may be best to use the CollationElementIterator interface, which does have a reset method on it, thus allowing it to be reused.

Of course writing some test cases (which could be done outside of the engine, just using the types api) would be the best place to start and then looking at the various approaches.

> caching collation elements in WorkHorseForCollatorDatatypes may improve performance.
> ------------------------------------------------------------------------------------
>
>                 Key: DERBY-2698
>                 URL: https://issues.apache.org/jira/browse/DERBY-2698
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.3.0.0
>            Reporter: Mike Matrigali
>            Priority: Minor
>
> In java/engine/org/apache/derby/iapi/types/WorkHorseForCollatorDatatypes.getCollationElementsForString() an array
> of int's is calculated given the string and the collator in place.  If like is ever called on the same DataValueDescriptor, caching
> this calculation will be faster than redoing the calculation.  To make this change one needs to properly invalidate the cached
> information when the base type value is changed.  For instance in the case of SQLChar() the following routines all result
> in a change in the value of the datatype and thus need to invalidate any cached collation element structure:
> readExternalFromArray()
> readExternal()
> setValue()
> there may be others.
> DERBY-2670 is an example of what can go wrong if you get the caching wrong.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.