db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2698) caching collation elements in WorkHorseForCollatorDatatypes may improve performance.
Date Sat, 26 May 2007 16:18:16 GMT

    [ 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:
>            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.

View raw message