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

James Taylor commented on PHOENIX-1315:
---------------------------------------

Best would be to have the equivalent of a where clause/filter on your load 
command, but I believe even the above would use the index. Can you specify a 
filter using the load command? If not, this is ok. Also, add one for the load 
command that let's you specify a query and in that case specify a where clause 
on the column you're indexing (i.e. NAME).

Is there any way to verify in the test that the index table is used to service 
the load command? At a minimum, confirm in the debugger.


> 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)

Reply via email to