[DERBY-2698] caching collation elements in WorkHorseForCollatorDatatypes may improve performance.

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 10.3.1.4
• Component/s: SQL
• Labels: derby_triage10_10
• Urgency: Normal
• Assignee: Unassigned
• Reporter: Mike Matrigali
• Created: 26/May/07 00:09
• Updated: 03/Jan/13 12:20

Description

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.

Issue Links

• is related to: DERBY-2670 %a% and %aa% match too many rows in database with collation=TERRITORY_BASED and territory=no_NO
• is related to: DERBY-2699 performance of like in territory based collation databases may be improved by changing way collation elements are calculated.
• is related to: DERBY-3136 Cut down on object creations in LIKE clause implementation of territory based characters.