[
https://issues.apache.org/jira/browse/DERBY-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627040#action_12627040
]
Rick Hillegas commented on DERBY-3854:
--------------------------------------
Hi Knut,
This looks like a promising approach. It certainly seems that we ought to be
able to find a longest, well-behaved leading prefix of the LIKE constant--and
then build bounds from that prefix. Your rules look good to me. That is, I
haven't been able to come up with a problem case. That's a bit shy of proof, of
course. And I am a bit muddled by the interaction of the Collator levers,
strength and decomposition.
> Implement LIKE transformations and optimizations for databases using
> territory-based collations
> -----------------------------------------------------------------------------------------------
>
> Key: DERBY-3854
> URL: https://issues.apache.org/jira/browse/DERBY-3854
> Project: Derby
> Issue Type: Improvement
> Affects Versions: 10.3.3.0, 10.4.1.3, 10.5.0.0
> Reporter: Rick Hillegas
>
> The LIKE transformations and optimizations are disabled when using a database
> with a territory-based collation. See the following email thread:
> http://www.nabble.com/territory-based-collations-and-optimizations-for-the-LIKE-operator-td19111725.html#a19111725
> That thread, in turn, refers to DERBY-1478. It would be nice if we did not
> have to perform full table scans for LIKE queries in databases with
> territory-based collations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
