You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "ravi (JIRA)" <ji...@apache.org> on 2014/10/06 10:52:33 UTC

[jira] [Comment Edited] (PHOENIX-1315) Optimize query for Pig loader

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

ravi edited comment on PHOENIX-1315 at 10/6/14 8:51 AM:
--------------------------------------------------------

[~giacomotaylor]] , The alias that the user specifies using the AS clause within LOAD statement can be used downstream in the Pig script . If the user specifies a different alias name as part of AS within the LOAD clause for a column , for instance instead of NAME he specifies as USERNAME , then if we take the alias name, the SELECT query will fail.   
  Apparently, what we are doing currently is given a table name within LOAD , we internally make a call to PhoenixRuntime.generateColumnInfo to get the list of ColumnInfo and construct the SELECT query. I believe we need to make a change within ColumnInfo.fromString  method to handle this case when index columns are passed.   

{code}
pigServer.registerQuery(String.format(
	                "A = load 'hbase://table/I' using " + PhoenixHBaseLoader.class.getName() + "('%s') AS (NAME:chararray,ID:int,AGE:int) ;", zkQuorum));
{code}




was (Author: maghamravikiran):
[~James] , The alias that the user specifies using the AS clause within LOAD statement can be used downstream in the Pig script . If the user specifies a different alias name as part of AS within the LOAD clause for a column , for instance instead of NAME he specifies as USERNAME , then if we take the alias name, the SELECT query will fail.   
  Apparently, what we are doing currently is given a table name within LOAD , we internally make a call to PhoenixRuntime.generateColumnInfo to get the list of ColumnInfo and construct the SELECT query. I believe we need to make a change within ColumnInfo.fromString  method to handle this case when index columns are passed.   

{code}
pigServer.registerQuery(String.format(
	                "A = load 'hbase://table/I' using " + PhoenixHBaseLoader.class.getName() + "('%s') AS (NAME:chararray,ID:int,AGE:int) ;", zkQuorum));
{code}



> Optimize query for Pig loader
> -----------------------------
>
>                 Key: PHOENIX-1315
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1315
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: maghamravikiran
>             Fix For: 4.2, 3.2
>
>         Attachments: PHOENIX-1315.patch, PHOENIX-1315_v2.patch, PHOENIX-1315_v3.patch, PHOENIX-1315_v4.patch
>
>
> I came across this with a recent change I was making. Why is the call to queryPlan.iterators() necessary in PhoenixInputFormat?
> {code}
>     private QueryPlan getQueryPlan(final JobContext context) throws IOException {
>         Preconditions.checkNotNull(context);
>         if(queryPlan == null) {
>             try{
>                 final Connection connection = getConnection();
>                 final String selectStatement = getConf().getSelectStatement();
>                 Preconditions.checkNotNull(selectStatement);
>                 final Statement statement = connection.createStatement();
>                 final PhoenixStatement pstmt = statement.unwrap(PhoenixStatement.class);
>                 this.queryPlan = pstmt.compileQuery(selectStatement);
>                 // FIXME: why is getting the iterator necessary here, as it will
>                 // cause the query to run.
>                 this.queryPlan.iterator();
>             } catch(Exception exception) {
>                 LOG.error(String.format("Failed to get the query plan with error [%s]",exception.getMessage()));
>                 throw new RuntimeException(exception);
>             }
>         }
>         return queryPlan;
>     }
> {code}



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