phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-2163) Measure performance of Phoenix/Calcite querying
Date Sat, 15 Aug 2015 17:44:45 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14698370#comment-14698370
] 

James Taylor commented on PHOENIX-2163:
---------------------------------------

Excellent, [~shuxi0ng]. Please review and commit, [~maryannxue]. 

Regarding CASE and CASE/WHEN both are compiled to the same expression: CaseExpression. Does
Calcite have different RexNodes for CASE versus CASE/WHEN? You can look at the case_statement
rule in PhoenixSQL.g for how we translate at parse time a CASE <e> WHEN <v1> THEN
<e1> WHEN <v2> THEN <e2> END. We basically translate it to a CASE WHEN <e>
= <v1> THEN <e1> WHEN <e> = <v2> THEN <e2> END. If need be,
you could do that translation in your factory.

For CaseExpression, the List<Expression> children need to be in the following order:
<when expression1><then expression1><when expression2><then expression2>...<optional
else expression>.

For example, given this CASE statement: CASE WHEN c1 = 'a' THEN 'b' WHEN c2 = 'b' THEN 'c'
ELSE 'd' END, we'd end up with the following List<Expression>: 'b', c1 = 'a', 'c', c2
= 'b', 'd'

We know if there's an else clause based on the size of the list being an odd number.

> Measure performance of Phoenix/Calcite querying
> -----------------------------------------------
>
>                 Key: PHOENIX-2163
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2163
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: Shuxiong Ye
>         Attachments: PHOENIX-2163.patch
>
>
> The work to integrate Phoenix with Calcite has come along far enough that queries both
against the data table and through a secondary index is functional. As a checkpoint, we should
compare performance of as many queries as possible in our regression suite for the calcite
branch against the latest Phoenix release (4.5.0). The runtime of these two systems should
be the same, so this will give us an idea of the overhead of query parsing and compilation
for Calcite. This is super important, as it'll identify outstanding work that'll be necessary
to do prior to any releases on top of this new stack.
> Source code of regression suite is at https://github.com/mujtabachohan/PhoenixRegressor
> Connection string location: https://github.com/mujtabachohan/PhoenixRegressor/blob/master/src/main/resources/settings.json
> Instructions on how to compile and run: https://github.com/mujtabachohan/PhoenixRegressor/blob/master/README.md



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message