date:20190123

[jira] [Updated] (PHOENIX-5106) Avoid getting an explain plan for each query (even without tracing)

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-5106:
---
Attachment: 5106-v1.txt

> Avoid getting an explain plan for each query (even without tracing)
> ---
>
> Key: PHOENIX-5106
> URL: https://issues.apache.org/jira/browse/PHOENIX-5106
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
>  Labels: performance
> Attachments: 5106-v1.txt, 5106.txt
>
>
> See this code fragment in BaseQueryPlan.iterator(...):
> {code}
> // wrap the iterator so we start/end tracing as we expect
> TraceScope scope =
> Tracing.startNewSpan(context.getConnection(), "Creating basic 
> query for "
> + getPlanSteps(iterator));
> return (scope.getSpan() != null) ? new TracingIterator(scope, 
> iterator) : iterator;
> {code}
> This will get the plan steps for each and every call to iterator, whether 
> we're tracing or not.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Will Global Phoenix Client Metrics for PQS be supported on next CDH release

2019-01-23 Thread Mahdi Salarkia

Hi
I'm interested to know more about the status of PHOENIX-3655
 in the upcoming
release.
Currently we use 4.14.0-cdh5.11.2 of Apache Phoenix and Hbase 1.2.0.
Based on the ticket it looks like this feature will be available on version
4.15 however looking at the code seems like this is fixed for Hbase 2.0
which we are not planning to upgrade to yet.
It would be much appreciated if you clarify.
Also do you have a rough estimate on when would be the next release for
Phoenix that include these fixes?

Best
Mehdi

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-5109:
---
Attachment: 5109-v3.txt

> Hinted local index with uncovered column in the WHERE clause throws an 
> exception.
> -
>
> Key: PHOENIX-5109
> URL: https://issues.apache.org/jira/browse/PHOENIX-5109
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
> Attachments: 5109-v1.txt, 5109-v2.txt, 5109-v3.txt
>
>
> Example:
> {{create table test (pk integer primary key, v1 float, v2 float, v3 
> integer);}}
> {{create local index l1 on test(v1);}}
> {{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}
> {code}
> 0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 
> = 1;
> Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): 
> Undefined column. columnName=TEST.V2
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
>   at 
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at 
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:813)
>   at sqlline.SqlLine.begin(SqlLine.java:686)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (PHOENIX-2404) Create builder to construct PTableImpl

2019-01-23 Thread Thomas D'Silva (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas D'Silva resolved PHOENIX-2404.
-
Resolution: Fixed

> Create builder to construct PTableImpl 
> ---
>
> Key: PHOENIX-2404
> URL: https://issues.apache.org/jira/browse/PHOENIX-2404
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Thomas D'Silva
>Assignee: churro morales
>Priority: Minor
>  Labels: newbie
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl reassigned PHOENIX-5109:
--

Assignee: Lars Hofhansl

> Hinted local index with uncovered column in the WHERE clause throws an 
> exception.
> -
>
> Key: PHOENIX-5109
> URL: https://issues.apache.org/jira/browse/PHOENIX-5109
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Lars Hofhansl
>Assignee: Lars Hofhansl
>Priority: Major
> Attachments: 5109-v1.txt, 5109-v2.txt
>
>
> Example:
> {{create table test (pk integer primary key, v1 float, v2 float, v3 
> integer);}}
> {{create local index l1 on test(v1);}}
> {{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}
> {code}
> 0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 
> = 1;
> Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): 
> Undefined column. columnName=TEST.V2
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
>   at 
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at 
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:813)
>   at sqlline.SqlLine.begin(SqlLine.java:686)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-5109:
---
Attachment: 5109-v2.txt

> Hinted local index with uncovered column in the WHERE clause throws an 
> exception.
> -
>
> Key: PHOENIX-5109
> URL: https://issues.apache.org/jira/browse/PHOENIX-5109
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Lars Hofhansl
>Priority: Major
> Attachments: 5109-v1.txt, 5109-v2.txt
>
>
> Example:
> {{create table test (pk integer primary key, v1 float, v2 float, v3 
> integer);}}
> {{create local index l1 on test(v1);}}
> {{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}
> {code}
> 0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 
> = 1;
> Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): 
> Undefined column. columnName=TEST.V2
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
>   at 
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at 
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:813)
>   at sqlline.SqlLine.begin(SqlLine.java:686)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5110) java.lang.IllegalArgumentException when using hint with delete.

2019-01-23 Thread Hans Deragon (JIRA)

Hans Deragon created PHOENIX-5110:
-

 Summary: java.lang.IllegalArgumentException when using hint with 
delete.
 Key: PHOENIX-5110
 URL: https://issues.apache.org/jira/browse/PHOENIX-5110
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 4.14.0
Reporter: Hans Deragon


Running the following works:
{noformat}
jdbc:phoenix:> select /*+ USE_SORT_MERGE_JOIN */ * from mytable where not 
exists (select primarykey from mytable_staging where mytable.primarykey = 
mytable_staging.primarykey);
 All rows that exist in mytable but do not exist in mytable_staging show 
up.{noformat}
Replace 'select' with 'delete', remove the '*' with the hope to delete the 
rows.  The following error occurs:
{noformat}
jdbc:phoenix:> delete /*+ USE_SORT_MERGE_JOIN */ from mytable where not exists 
(select primarykey from mytable_staging where mytable.primarykey = 
mytable_staging.primarykey);
java.lang.IllegalArgumentException
at org.apache.phoenix.index.IndexMaintainer.create(IndexMaintainer.java:141)
at org.apache.phoenix.compile.DeleteCompiler.deleteRows(DeleteCompiler.java:216)
at org.apache.phoenix.compile.DeleteCompiler.access$000(DeleteCompiler.java:98)
at 
org.apache.phoenix.compile.DeleteCompiler$ClientSelectDeleteMutationPlan.execute(DeleteCompiler.java:937)
at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:408)
at org.apache.phoenix.jdbc.PhoenixStatement$2.call(PhoenixStatement.java:391)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:390)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeMutation(PhoenixStatement.java:378)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1825)
at sqlline.Commands.execute(Commands.java:822)
at sqlline.Commands.sql(Commands.java:732)
at sqlline.SqlLine.dispatch(SqlLine.java:813)
at sqlline.SqlLine.begin(SqlLine.java:686)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:291){noformat}
Using:  *phoenix-4.14.0-1.amzn1.noarch*



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-5109:
---
Attachment: 5109-v1.txt

> Hinted local index with uncovered column in the WHERE clause throws an 
> exception.
> -
>
> Key: PHOENIX-5109
> URL: https://issues.apache.org/jira/browse/PHOENIX-5109
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Lars Hofhansl
>Priority: Major
> Attachments: 5109-v1.txt
>
>
> Example:
> {{create table test (pk integer primary key, v1 float, v2 float, v3 
> integer);}}
> {{create local index l1 on test(v1);}}
> {{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}
> {code}
> 0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 
> = 1;
> Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): 
> Undefined column. columnName=TEST.V2
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
>   at 
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at 
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:813)
>   at sqlline.SqlLine.begin(SqlLine.java:686)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)

Lars Hofhansl created PHOENIX-5109:
--

 Summary: Hinted local index with uncovered column in the WHERE 
clause throws an exception.
 Key: PHOENIX-5109
 URL: https://issues.apache.org/jira/browse/PHOENIX-5109
 Project: Phoenix
  Issue Type: Bug
Reporter: Lars Hofhansl


Example:
{{create table test (pk integer primary key, v1 float, v2 float, v3 integer);}}
{{create local index l1 on test(v1);}}
{{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}

{code}
0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 = 
1;
Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
(state=42703,code=504)
org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): Undefined 
column. columnName=TEST.V2
at 
org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
at 
org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
at 
org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
at 
org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
at 
org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
at 
org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
at 
org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
at 
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
at 
org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
at 
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
at 
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
at 
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
at 
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
at 
org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
at 
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
at 
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
at 
org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
at 
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
at 
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
at 
org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
at 
org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
at 
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
at 
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
at 
org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
at 
org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
at 
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
at 
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
at 
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
at 
org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
at sqlline.Commands.execute(Commands.java:822)
at sqlline.Commands.sql(Commands.java:732)
at sqlline.SqlLine.dispatch(SqlLine.java:813)
at sqlline.SqlLine.begin(SqlLine.java:686)
at sqlline.SqlLine.start(SqlLine.java:398)
at sqlline.SqlLine.main(SqlLine.java:291)
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

2019-01-23 Thread Lars Hofhansl (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Hofhansl updated PHOENIX-5109:
---
Affects Version/s: 4.14.1

> Hinted local index with uncovered column in the WHERE clause throws an 
> exception.
> -
>
> Key: PHOENIX-5109
> URL: https://issues.apache.org/jira/browse/PHOENIX-5109
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Lars Hofhansl
>Priority: Major
>
> Example:
> {{create table test (pk integer primary key, v1 float, v2 float, v3 
> integer);}}
> {{create local index l1 on test(v1);}}
> {{select /*+ INDEX(test l1) */ * from test where v2 = 1;}}
> {code}
> 0: jdbc:phoenix:localhost> select /*+ INDEX(test l1) */ * from test where v2 
> = 1;
> Error: ERROR 504 (42703): Undefined column. columnName=TEST.V2 
> (state=42703,code=504)
> org.apache.phoenix.schema.ColumnNotFoundException: ERROR 504 (42703): 
> Undefined column. columnName=TEST.V2
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.resolveColumn(WhereCompiler.java:202)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:177)
>   at 
> org.apache.phoenix.compile.WhereCompiler$WhereExpressionCompiler.visit(WhereCompiler.java:164)
>   at 
> org.apache.phoenix.parse.ColumnParseNode.accept(ColumnParseNode.java:56)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at org.apache.phoenix.parse.CastParseNode.accept(CastParseNode.java:60)
>   at 
> org.apache.phoenix.parse.CompoundParseNode.acceptChildren(CompoundParseNode.java:64)
>   at 
> org.apache.phoenix.parse.ComparisonParseNode.accept(ComparisonParseNode.java:45)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:138)
>   at 
> org.apache.phoenix.compile.WhereCompiler.compile(WhereCompiler.java:108)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:559)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:510)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:195)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSubquery(QueryCompiler.java:499)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:221)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:295)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileJoinQuery(QueryCompiler.java:230)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:193)
>   at 
> org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:155)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:399)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:279)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:220)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:133)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:111)
>   at 
> org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:97)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:309)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
>   at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:283)
>   at 
> org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:1830)
>   at sqlline.Commands.execute(Commands.java:822)
>   at sqlline.Commands.sql(Commands.java:732)
>   at sqlline.SqlLine.dispatch(SqlLine.java:813)
>   at sqlline.SqlLine.begin(SqlLine.java:686)
>   at sqlline.SqlLine.start(SqlLine.java:398)
>   at sqlline.SqlLine.main(SqlLine.java:291)
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5069) Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache

2019-01-23 Thread Bin Shi (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bin Shi updated PHOENIX-5069:
-
Attachment: PHOENIX-5069.master.003.patch

> Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache
> ---
>
> Key: PHOENIX-5069
> URL: https://issues.apache.org/jira/browse/PHOENIX-5069
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Bin Shi
>Assignee: Bin Shi
>Priority: Major
> Attachments: PHOENIX-5069.master.001.patch, 
> PHOENIX-5069.master.002.patch, PHOENIX-5069.master.003.patch, 
> PHOENIX-5069.patch
>
>  Time Spent: 6h 40m
>  Remaining Estimate: 0h
>
> The current Phoenix Stats Cache uses TTL based eviction policy. A cached 
> entry will expire after a given amount of time (900s by default) passed since 
> the entry's been created. This will lead to cache miss when 
> Compiler/Optimizer fetches stats from cache at the next time. As you can see 
> from the above graph, fetching stats from the cache is a blocking operation — 
> when there is cache miss, it has a round trip over the wire to scan the 
> SYSTEM.STATS Table and to get the latest stats info, rebuild the cache and 
> finally return the stats to the Compiler/Optimizer. Whenever there is a cache 
> miss, this blocking call causes significant performance penalty and see 
> periodic spikes.
> *This Jira suggests to use asynchronous refresh mechanism to provide a 
> non-blocking cache. For details, please see the linked design document below.*
> [~karanmehta93] [~twdsi...@gmail.com] [~dbwong] [~elserj] [~an...@apache.org] 
> [~sergey soldatov] 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4009) Run UPDATE STATISTICS command by using MR integration on snapshots

2019-01-23 Thread Karan Mehta (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Karan Mehta updated PHOENIX-4009:
-
Labels: stats statsCollection  (was: )

> Run UPDATE STATISTICS command by using MR integration on snapshots
> --
>
> Key: PHOENIX-4009
> URL: https://issues.apache.org/jira/browse/PHOENIX-4009
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Samarth Jain
>Assignee: Karan Mehta
>Priority: Major
>  Labels: stats, statsCollection
> Attachments: PHOENIX-4009.4.x-HBase-1.4.001.patch, 
> PHOENIX-4009.4.x-HBase-1.4.002.patch, PHOENIX-4009.master.001.patch
>
>  Time Spent: 13h
>  Remaining Estimate: 0h
>
> Now that we have the capability to run queries against table snapshots 
> through our map reduce integration, we can utilize this capability for stats 
> collection too. This would make our stats collection more resilient, resource 
> aware and less resource intensive. The bulk of the plumbing is already in 
> place. We would need to make sure that the integration doesn't barf when the 
> query is an UPDATE STATISTICS command.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5105) Push Filter through Sort for SortMergeJoin

2019-01-23 Thread chenglei (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-5105:
--
Description: 
Given two tables:
{code:java}
  CREATE TABLE merge1 ( 
aid INTEGER PRIMARY KEY,
age INTEGER)
  

  CREATE TABLE merge2  ( 
bid INTEGER PRIMARY KEY,
code INTEGER)
{code}
for following sql :
{code:java}
select /*+ USE_SORT_MERGE_JOIN */ a.aid,b.code from 
(select aid,age from merge1 where age >=11 and age<=33 order by age limit 3) a 
inner join 
(select bid,code from merge2 order by code limit 1) b on a.aid=b.bid where 
b.code > 50
{code}
For the RHS of SortMergeJoin, at first the where condition {{b.code > 50}} is 
pushed down to RHS as its {{JoinCompiler.Table.postFilters}},  then {{order by 
b.bid}} is appended to RHS and it is rewritten as 
 {{select bid,code from (select bid,code from merge2 order by code limit 1) 
order by bid}}

by following line 211 in {{QueryCompiler.compileJoinQuery}}.

Next the above rewritten sql is compiled to ClientScanPlan by following line 
221 ,and previously pushed down {{b.code > 50}} is compiled by 
{{table.compilePostFilterExpression}} method in following line 224 to filter 
the result of the preceding ClientScanPlan. The problem here is that we execute 
the {{order by bid}} first and then the postFilter {{b.code > 50}}, obviously 
it is inefficient. In fact, we can directly rewrite the RHS as 
 {{select bid,code from (select bid,code from merge2 order by code limit 1) 
order by bid where code > 50}} 
 to first filter {{b.code > 50}} and then execute the {{order by bid}} .
{code:java}
208protected QueryPlan compileJoinQuery(StatementContext context, 
List binds, JoinTable joinTable, boolean asSubquery, boolean 
projectPKColumns, List orderBy) throws SQLException {
209 if (joinTable.getJoinSpecs().isEmpty()) {
210  Table table = joinTable.getTable();
211   SelectStatement subquery = table.getAsSubquery(orderBy);
212  if (!table.isSubselect()) {
213  context.setCurrentTable(table.getTableRef());
214  PTable projectedTable = 
table.createProjectedTable(!projectPKColumns, context);
215  TupleProjector projector = new 
TupleProjector(projectedTable);
216  
TupleProjector.serializeProjectorIntoScan(context.getScan(), projector);
217  
context.setResolver(FromCompiler.getResolverForProjectedTable(projectedTable, 
context.getConnection(), subquery.getUdfParseNodes()));
218  table.projectColumns(context.getScan());
219  return compileSingleFlatQuery(context, subquery, binds, 
asSubquery, !asSubquery, null, projectPKColumns ? projector : null, true);
220}
221QueryPlan plan = compileSubquery(subquery, false);
222PTable projectedTable = 
table.createProjectedTable(plan.getProjector());
223
context.setResolver(FromCompiler.getResolverForProjectedTable(projectedTable, 
context.getConnection(), subquery.getUdfParseNodes()));
224return new TupleProjectionPlan(plan, new 
TupleProjector(plan.getProjector()), 
table.compilePostFilterExpression(context));
225}
{code}

  was:
Given two tables:
{code}
  CREATE TABLE merge1 ( 
aid INTEGER PRIMARY KEY,
age INTEGER)
  

  CREATE TABLE merge2  ( 
bid INTEGER PRIMARY KEY,
code INTEGER)
{code}

for following sql :
{code}
select /*+ USE_SORT_MERGE_JOIN */ a.aid,b.code from 
(select aid,age from merge1 where age >=11 and age<=33 order by age limit 3) a 
inner join 
(select bid,code from merge2 order by code limit 1) b on a.aid=b.bid where 
b.code > 50
{code}

For the RHS of SortMergeJoin, at first the where condition {{b.code > 50}} is 
pushed down to RHS as its {{JoinCompiler.Table.postFilters}}, and then {{order 
by b.bid}} is appended to RHS , finally the RHS is rewritten as 
 {{select bid,code from (select bid,code from merge2 order by code limit 1) 
order by bid}} by following line 211 in {{QueryCompiler.compileJoinQuery}}. 

The rewritten sql  is  then compiled to ClientScanPlan by following line 221 
,and previously pushed down {{b.code > 50}} is compiled by 
{{table.compilePostFilterExpression}} method in following line 224 to filter 
the result of the preceding ClientScanPlan. The problem here is that we execute 
the {{order by bid}} first and then the postFilter {{b.code > 50}}, obviously 
it is inefficient. In fact, we can directly rewrite the RHS as 
{{select bid,code from (select bid,code from merge2 order by code limit 1) 
order by bid where code > 50}} 
to first filter {{b.code > 50}} and then execute the {{order by bid}} .



{code}
208protected QueryPlan compileJoinQuery(StatementContext

[jira] [Updated] (PHOENIX-5105) Push Filter through Sort for SortMergeJoin

2019-01-23 Thread chenglei (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

chenglei updated PHOENIX-5105:
--
Attachment: PHOENIX-5015_v2-4.x-HBase-1.4.patch

> Push Filter through Sort for SortMergeJoin
> --
>
> Key: PHOENIX-5105
> URL: https://issues.apache.org/jira/browse/PHOENIX-5105
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 4.14.1
>Reporter: chenglei
>Assignee: chenglei
>Priority: Major
> Fix For: 4.15.0
>
> Attachments: PHOENIX-5015-4.x-HBase-1.4.patch, 
> PHOENIX-5015_v2-4.x-HBase-1.4.patch
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Given two tables:
> {code}
>   CREATE TABLE merge1 ( 
> aid INTEGER PRIMARY KEY,
> age INTEGER)
>   
>   CREATE TABLE merge2  ( 
> bid INTEGER PRIMARY KEY,
> code INTEGER)
> {code}
> for following sql :
> {code}
> select /*+ USE_SORT_MERGE_JOIN */ a.aid,b.code from 
> (select aid,age from merge1 where age >=11 and age<=33 order by age limit 3) 
> a inner join 
> (select bid,code from merge2 order by code limit 1) b on a.aid=b.bid where 
> b.code > 50
> {code}
> For the RHS of SortMergeJoin, at first the where condition {{b.code > 50}} is 
> pushed down to RHS as its {{JoinCompiler.Table.postFilters}}, and then 
> {{order by b.bid}} is appended to RHS , finally the RHS is rewritten as 
>  {{select bid,code from (select bid,code from merge2 order by code limit 1) 
> order by bid}} by following line 211 in {{QueryCompiler.compileJoinQuery}}. 
> The rewritten sql  is  then compiled to ClientScanPlan by following line 221 
> ,and previously pushed down {{b.code > 50}} is compiled by 
> {{table.compilePostFilterExpression}} method in following line 224 to filter 
> the result of the preceding ClientScanPlan. The problem here is that we 
> execute the {{order by bid}} first and then the postFilter {{b.code > 50}}, 
> obviously it is inefficient. In fact, we can directly rewrite the RHS as 
> {{select bid,code from (select bid,code from merge2 order by code limit 1) 
> order by bid where code > 50}} 
> to first filter {{b.code > 50}} and then execute the {{order by bid}} .
> {code}
> 208protected QueryPlan compileJoinQuery(StatementContext context, 
> List binds, JoinTable joinTable, boolean asSubquery, boolean 
> projectPKColumns, List orderBy) throws SQLException {
> 209 if (joinTable.getJoinSpecs().isEmpty()) {
> 210  Table table = joinTable.getTable();
> 211   SelectStatement subquery = table.getAsSubquery(orderBy);
> 212  if (!table.isSubselect()) {
> 213  context.setCurrentTable(table.getTableRef());
> 214  PTable projectedTable = 
> table.createProjectedTable(!projectPKColumns, context);
> 215  TupleProjector projector = new 
> TupleProjector(projectedTable);
> 216  
> TupleProjector.serializeProjectorIntoScan(context.getScan(), projector);
> 217  
> context.setResolver(FromCompiler.getResolverForProjectedTable(projectedTable, 
> context.getConnection(), subquery.getUdfParseNodes()));
> 218  table.projectColumns(context.getScan());
> 219  return compileSingleFlatQuery(context, subquery, binds, 
> asSubquery, !asSubquery, null, projectPKColumns ? projector : null, true);
> 220}
> 221QueryPlan plan = compileSubquery(subquery, false);
> 222PTable projectedTable = 
> table.createProjectedTable(plan.getProjector());
> 223
> context.setResolver(FromCompiler.getResolverForProjectedTable(projectedTable, 
> context.getConnection(), subquery.getUdfParseNodes()));
> 224return new TupleProjectionPlan(plan, new 
> TupleProjector(plan.getProjector()), 
> table.compilePostFilterExpression(context));
> 225}
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-4296) Dead loop in HBase reverse scan when amount of scan data is greater than SCAN_RESULT_CHUNK_SIZE

2019-01-23 Thread Chen Feng (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chen Feng updated PHOENIX-4296:
---
Attachment: PHOENIX-4296-4.x-HBase-1.2-v2.patch

> Dead loop in HBase reverse scan when amount of scan data is greater than 
> SCAN_RESULT_CHUNK_SIZE
> ---
>
> Key: PHOENIX-4296
> URL: https://issues.apache.org/jira/browse/PHOENIX-4296
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.6.0
>Reporter: rukawakang
>Priority: Major
> Attachments: PHOENIX-4296-4.x-HBase-1.2-v2.patch, 
> PHOENIX-4296-4.x-HBase-1.2.patch, PHOENIX-4296.patch
>
>
> This problem seems to only occur with reverse scan not forward scan. When 
> amount of scan data is greater than SCAN_RESULT_CHUNK_SIZE(default 2999), 
> Class ChunkedResultIteratorFactory will multiple calls function 
> getResultIterator. But in function getResultIterator it always readjusts 
> startRow, in fact, if in reverse scan we should readjust stopRow. For example 
> {code:java}
> if (ScanUtil.isReversed(scan)) {
> scan.setStopRow(ByteUtil.copyKeyBytesIfNecessary(lastKey));
> } else {
> scan.setStartRow(ByteUtil.copyKeyBytesIfNecessary(lastKey));
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client

2019-01-23 Thread Kiran Kumar Maturi (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Kumar Maturi updated PHOENIX-5094:

Attachment: PHOENIX-5094-4.14-HBase-1.3.01.patch

> Index can transition from INACTIVE to ACTIVE via Phoenix Client
> ---
>
> Key: PHOENIX-5094
> URL: https://issues.apache.org/jira/browse/PHOENIX-5094
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Monani Mihir
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch
>
>
> Suppose Index is in INACTIVE state and Client load is running continuously. 
> With INACTIVE State, client will keep maintaining index.
> Before Rebuilder could run and bring index back in sync with data table, If 
> some mutation for Index fails from client side, then client will transition 
> Index state (From INACTIVE--> PENDING_DISABLE).
> If client succeeds in writing mutation in subsequent retries, it will 
> transition Index state again ( From PENDING_DISABLE --> ACTIVE) .
> Above scenario will leave some part of Index out of sync with data table.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client

2019-01-23 Thread Kiran Kumar Maturi (JIRA)



 [ 
https://issues.apache.org/jira/browse/PHOENIX-5094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kiran Kumar Maturi updated PHOENIX-5094:

Attachment: (was: PHOENIX-5094-4.14-HBase-1.3.01.patch)

> Index can transition from INACTIVE to ACTIVE via Phoenix Client
> ---
>
> Key: PHOENIX-5094
> URL: https://issues.apache.org/jira/browse/PHOENIX-5094
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0, 4.14.1
>Reporter: Monani Mihir
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Attachments: PHOENIX-5094-4.14-HBase-1.3.01.patch
>
>
> Suppose Index is in INACTIVE state and Client load is running continuously. 
> With INACTIVE State, client will keep maintaining index.
> Before Rebuilder could run and bring index back in sync with data table, If 
> some mutation for Index fails from client side, then client will transition 
> Index state (From INACTIVE--> PENDING_DISABLE).
> If client succeeds in writing mutation in subsequent retries, it will 
> transition Index state again ( From PENDING_DISABLE --> ACTIVE) .
> Above scenario will leave some part of Index out of sync with data table.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (PHOENIX-5106) Avoid getting an explain plan for each query (even without tracing)

Will Global Phoenix Client Metrics for PQS be supported on next CDH release

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Resolved] (PHOENIX-2404) Create builder to construct PTableImpl

[jira] [Assigned] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Created] (PHOENIX-5110) java.lang.IllegalArgumentException when using hint with delete.

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Created] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Updated] (PHOENIX-5109) Hinted local index with uncovered column in the WHERE clause throws an exception.

[jira] [Updated] (PHOENIX-5069) Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache

[jira] [Updated] (PHOENIX-4009) Run UPDATE STATISTICS command by using MR integration on snapshots

[jira] [Updated] (PHOENIX-5105) Push Filter through Sort for SortMergeJoin

[jira] [Updated] (PHOENIX-5105) Push Filter through Sort for SortMergeJoin

[jira] [Updated] (PHOENIX-4296) Dead loop in HBase reverse scan when amount of scan data is greater than SCAN_RESULT_CHUNK_SIZE

[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client

[jira] [Updated] (PHOENIX-5094) Index can transition from INACTIVE to ACTIVE via Phoenix Client

17 matches

Site Navigation

Mail list logo

Footer information