[
https://issues.apache.org/jira/browse/DRILL-4573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15287608#comment-15287608
]
ASF GitHub Bot commented on DRILL-4573:
---------------------------------------
Github user jinfengni commented on the pull request:
https://github.com/apache/drill/pull/458#issuecomment-219858967
@jcmcote ,
(copy from my comment in DRILL-4573)
I re-visited your first patch. Looks like that the change you made would
cause incorrect result when the input string is a udf-8 with each character
consisting of multiple bytes. In particular, the original implementation would
encode the byte array with udf-8 (which is the default encoding in drill).
However, in your CharSequenceWrapper, you will treat each byte as a character.
This will cause incorrect result for case when a character is represented by >1
bytes.
For instance, look at the following example, the first query of
regexp_matches will produce wrong result.
{code:sql}
select regexp_matches('München', 'München') res3 from (values(1));
+--------+
| res3 |
+--------+
| false |
+--------+
1 row selected (0.148 seconds)
0: jdbc:drill:zk=local> select regexp_matches('abc', 'abc') from
(values(1));
+---------+
| EXPR$0 |
+---------+
| true |
+---------+
1 row selected (0.189 seconds)
0: jdbc:drill:zk=local> select 'München' = 'München' res1 from (values(1));
+-------+
| res1 |
+-------+
| true |
+-------+
1 row selected (0.186 seconds)
{code:sql}
Here is the result for 1st query, without your patch
{code:sql}
select regexp_matches('München', 'München') res3 from (values(1));
+-------+
| res3 |
+-------+
| true |
+-------+
{code:sql}
I think you should modify CharSequenceWrapper, so that the encoding method
is honored.
> Zero copy LIKE, REGEXP_MATCHES, SUBSTR
> --------------------------------------
>
> Key: DRILL-4573
> URL: https://issues.apache.org/jira/browse/DRILL-4573
> Project: Apache Drill
> Issue Type: Improvement
> Reporter: jean-claude
> Priority: Minor
> Fix For: 1.7.0
>
> Attachments: DRILL-4573-3.patch.txt, DRILL-4573.patch.txt
>
>
> All the functions using the java.util.regex.Matcher are currently creating
> Java string objects to pass into the matcher.reset().
> However this creates unnecessary copy of the bytes and a Java string object.
> The matcher uses a CharSequence, so instead of making a copy we can create an
> adapter from the DrillBuffer to the CharSequence interface.
> Gains of 25% in execution speed are possible when going over VARCHAR of 36
> chars. The gain will be proportional to the size of the VARCHAR.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
