db-derby-dev mailing list archives

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

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

Mike Matrigali updated DERBY-2698:

I agree that caching may not be best approach, I just felt it important to log it as I was
backing it out so if anyone wanted to look closer  they 
could at least know what had been tried and not to make the same mistake as existed before.

For 10.3 I have no plans to work on either case, going to concentrate on getting right results.
 But I  do guess that there are a number of possible areas for future performance in territory
based collation for future releases.  

I don't really understand completely the possible codepaths using this code.  Can this code
path ever be called many times
on the same value in a single query.  Say in the case of some sort of join/subquery case where
it might be called once for
each row in another table?  

I think I agree that optimizing the case for DERBY-2699 seems more interesting and then after
that work it might be interesting to cache collation element work that may already have been
done in previous calls - really first need to understand how likely it is to use this twice
for a single value in DVD.

> 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