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