db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-2698) caching collation elements in WorkHorseForCollatorDatatypes may improve performance.
Date Tue, 02 Oct 2012 05:19:07 GMT

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

Mamta A. Satoor updated DERBY-2698:

    Urgency: Normal
     Labels: derby_triage10_10  (was: )
> 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
>              Labels: derby_triage10_10
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message