[DERBY-2699] performance of like in territory based collation databases may be improved by changing way collation elements are calculated.

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 10.3.1.4
• Fix Version/s: 10.9.2.2, 10.10.1.1
• Component/s: SQL
• Labels: derby_triage10_10
• Urgency: Normal
• Assignee: Mamta A. Satoor
• Reporter: Mike Matrigali
• Created: 26/May/07 00:21
• Updated: 05/Aug/13 06:35
• Resolved: 03/Jan/13 12:02

Description

WorkHorseForCollatorDatatypes.java has a method getCollationElementsForString() which currently gets
called when processing like clauses in databases that have been created with territory based collation, this is
not an issue in pre-10.3 databases or post 10.3 default databases.
getCollationElementsForString gets the collation elements for the entire value of the String held by
the datatype using the class.

If you take the case of pattern 'A%' and the value of datatype is 'BXXXXXXXXXXXXXXXXXXXXXXX',
then it would have been better to better to get collation elements one character of the String value at a time
to avoid the process of getting collation elements for the entire string when we don't really need it
One could imagine this might have a huge performance impact on running like against a long clob where
the like pattern has leading fixed-length pattern to match.

Comments on this from Dan and Dag can be found in DERBY-2416.

Issue Links

• relates to: DERBY-2698 caching collation elements in WorkHorseForCollatorDatatypes may improve performance.
• relates to: DERBY-3136 Cut down on object creations in LIKE clause implementation of territory based characters.