[jira] [Updated] (PHOENIX-6967) Empty cell generation in PostdDDLMutationPlan is executed serially
[ https://issues.apache.org/jira/browse/PHOENIX-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6967: - Description: The empty CQ generation after create table is not run in parallel. At first, I can see the read and writes on happening on each region, but after a minute or so, only one region is processed at a time in ascending order. My guess is that it has something to do with keepalive/chunked results not being processed on the client side correctly. was: The empty CQ generation after create table is not run in parallel. At first, I can see the read and writes on happening on each region, but after a minute or so, only one region region is processed at a time in ascending order. My guess is that it has something to do with keepalive/chunked results not being processed on the client side correctly. > Empty cell generation in PostdDDLMutationPlan is executed serially > -- > > Key: PHOENIX-6967 > URL: https://issues.apache.org/jira/browse/PHOENIX-6967 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > The empty CQ generation after create table is not run in parallel. > At first, I can see the read and writes on happening on each region, but > after a minute or so, only one region is processed at a time in ascending > order. > My guess is that it has something to do with keepalive/chunked results not > being processed on the client side correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-6967) Empty cell generation in PostdDDLMutationPlan is executed serially
[ https://issues.apache.org/jira/browse/PHOENIX-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6967: - Description: The empty CQ generation after create table is not run in parallel. At first, I can see the reads and writes on happening on each region, but after a minute or so, only one region is processed at a time in ascending order. My guess is that it has something to do with keepalive/chunked results not being processed on the client side correctly. was: The empty CQ generation after create table is not run in parallel. At first, I can see the read and writes on happening on each region, but after a minute or so, only one region is processed at a time in ascending order. My guess is that it has something to do with keepalive/chunked results not being processed on the client side correctly. > Empty cell generation in PostdDDLMutationPlan is executed serially > -- > > Key: PHOENIX-6967 > URL: https://issues.apache.org/jira/browse/PHOENIX-6967 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > The empty CQ generation after create table is not run in parallel. > At first, I can see the reads and writes on happening on each region, but > after a minute or so, only one region is processed at a time in ascending > order. > My guess is that it has something to do with keepalive/chunked results not > being processed on the client side correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-6961) Using a covered field in hinted non-covered indexed query fails
[
https://issues.apache.org/jira/browse/PHOENIX-6961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6961:
-
Description:
When covered fields are to be used in a hinted uncovered index lookup, Phoenix
fails with a bogus error message.
{noformat}
0: jdbc:phoenix:localhost:59972> create table d (v1 integer, k integer primary
key, v2 integer, v3 integer, v4 integer);
No rows affected (2.15 seconds)
0: jdbc:phoenix:localhost:59972> create index i on d(v2) include (v3);
No rows affected (7.177 seconds)
0: jdbc:phoenix:localhost:59972> select /*+ index(d i) */ * from d where v2=1
and v3=1;
Error: ERROR 514 (42892): A duplicate column name was detected in the object
definition or ALTER TABLE/VIEW statement. columnName=I.V1 (state=42892,code=514)
org.apache.phoenix.schema.ColumnAlreadyExistsException: ERROR 514 (42892): A
duplicate column name was detected in the object definition or ALTER TABLE/VIEW
statement. columnName=I.V1
at
org.apache.phoenix.schema.PTableImpl$Builder.initDerivedAttributes(PTableImpl.java:694)
at org.apache.phoenix.schema.PTableImpl$Builder.build(PTableImpl.java:802)
at
org.apache.phoenix.compile.TupleProjectionCompiler.createProjectedTable(TupleProjectionCompiler.java:179)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:701)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:667)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:249)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:348)
at
org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:302)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:230)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlans(QueryOptimizer.java:138)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:116)
at org.apache.phoenix.optimize.QueryOptimizer.optimize(QueryOptimizer.java:102)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:319)
at org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:301)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:300)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:293)
at org.apache.phoenix.jdbc.PhoenixStatement.execute(PhoenixStatement.java:2038)
at sqlline.Commands.executeSingleQuery(Commands.java:1130)
at sqlline.Commands.execute(Commands.java:1079)
at sqlline.Commands.sql(Commands.java:1033)
at sqlline.SqlLine.dispatch(SqlLine.java:822)
at sqlline.SqlLine.begin(SqlLine.java:596)
at sqlline.SqlLine.start(SqlLine.java:269)
at sqlline.SqlLine.main(SqlLine.java:208)
{noformat}
I thought that this was caused by the PK field not being the first, but the
same happens with:
{noformat}
create table d (k integer primary key, v1 integer, v2 integer, v3 integer, v4
integer);
{noformat}
was:
When covered fields are to be used in a hinted uncovered index lookup, Phoenix
fails with a bogus error message.
{noformat}
0: jdbc:phoenix:localhost:59972> create table d (v1 integer, k integer primary
key, v2 integer, v3 integer, v4 integer);
No rows affected (2.15 seconds)
0: jdbc:phoenix:localhost:59972> create index i on d(v2) include (v3);
No rows affected (7.177 seconds)
0: jdbc:phoenix:localhost:59972> select /*+ index(d i) */ * from d where v2=1
and v3=1;
Error: ERROR 514 (42892): A duplicate column name was detected in the object
definition or ALTER TABLE/VIEW statement. columnName=I.V1 (state=42892,code=514)
org.apache.phoenix.schema.ColumnAlreadyExistsException: ERROR 514 (42892): A
duplicate column name was detected in the object definition or ALTER TABLE/VIEW
statement. columnName=I.V1
at
org.apache.phoenix.schema.PTableImpl$Builder.initDerivedAttributes(PTableImpl.java:694)
at org.apache.phoenix.schema.PTableImpl$Builder.build(PTableImpl.java:802)
at
org.apache.phoenix.compile.TupleProjectionCompiler.createProjectedTable(TupleProjectionCompiler.java:179)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleFlatQuery(QueryCompiler.java:701)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:667)
at
org.apache.phoenix.compile.QueryCompiler.compileSelect(QueryCompiler.java:249)
at org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:178)
at org.apache.phoenix.optimize.QueryOptimizer.addPlan(QueryOptimizer.java:348)
at
org.apache.phoenix.optimize.QueryOptimizer.getHintedQueryPlan(QueryOptimizer.java:302)
at
org.apache.phoenix.optimize.QueryOptimizer.getApplicablePlansForSingleFlatQuery(QueryOptimizer.java:230)
at
[jira] [Updated] (PHOENIX-6954) Fix Category for some index related ITs
[ https://issues.apache.org/jira/browse/PHOENIX-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tanuj Khurana updated PHOENIX-6954: --- Fix Version/s: 5.1.4 (was: 5.1.3) > Fix Category for some index related ITs > --- > > Key: PHOENIX-6954 > URL: https://issues.apache.org/jira/browse/PHOENIX-6954 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Minor > Labels: test > Fix For: 5.2.0, 5.1.4 > > > I've noticed that some Index related ITs are never run by maven, because they > do not have a category defined. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-6967) Empty cell generation in PostdDDLMutationPlan is executed serially
[ https://issues.apache.org/jira/browse/PHOENIX-6967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6967: - Description: The empty CQ generation after create table is not run in parallel. At first, I can see the read and writes on happening on each region, but after a minute or so, only one region region is processed at a time in ascending order. My guess is that it has something to do with keepalive/chunked results not being processed on the client side correctly. was: The empty CQ generation after create table is not run in parallel. At first, I can see the read and writes on happening on each region, but after a minute or so, only one region region is processed at a time in ascending order. My guess is that it has somwthing to do with keepalive/chunked results not being processed on the client side. > Empty cell generation in PostdDDLMutationPlan is executed serially > -- > > Key: PHOENIX-6967 > URL: https://issues.apache.org/jira/browse/PHOENIX-6967 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > The empty CQ generation after create table is not run in parallel. > At first, I can see the read and writes on happening on each region, but > after a minute or so, only one region region is processed at a time in > ascending order. > My guess is that it has something to do with keepalive/chunked results not > being processed on the client side correctly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (PHOENIX-6966) UngroupedAggregateRegionScanner.insertEmptyKeyValue() writes wrong qualifier for encoded CQ tables
[ https://issues.apache.org/jira/browse/PHOENIX-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6966: - Description: We always use the non-encoded CQ when generating the empty cells. This results in extra "_0" empty cell being generated when re-recrating encoded qualifier Phoenix tables on existing HBase tables. was: We always use the nin-encoded CQ when generating the empty cells. This results in extra "_0" empty cell being generated when re-recrating encoded qualifier Phoenix tables on existing HBase tables. > UngroupedAggregateRegionScanner.insertEmptyKeyValue() writes wrong qualifier > for encoded CQ tables > -- > > Key: PHOENIX-6966 > URL: https://issues.apache.org/jira/browse/PHOENIX-6966 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > We always use the non-encoded CQ when generating the empty cells. > This results in extra "_0" empty cell being generated when re-recrating > encoded qualifier Phoenix tables on existing HBase tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Commit message formatting
Hi! Recently I have seen several commits where commit messages include all the messages from the incremental commits from development. While having well summarized extra information in a commit is generally fine, listing the commit messages for the interim commits doesn't add value. Those messages can easily be removed either when manually squashing the commits, or when using the Github squash feature. Please keep the commit messages free from these junk lines. regards Istvan
[jira] [Updated] (PHOENIX-6966) UngroupedAggregateRegionScanner.insertEmptyKeyValue() writes wrong qualifier for encoded CQ tables
[ https://issues.apache.org/jira/browse/PHOENIX-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6966: - Description: We always use the nin-encoded CQ when generating the empty cells. This results in extra "_0" empty cell being generated when re-recrating encoded qualifier Phoenix tables on existing HBase tables. > UngroupedAggregateRegionScanner.insertEmptyKeyValue() writes wrong qualifier > for encoded CQ tables > -- > > Key: PHOENIX-6966 > URL: https://issues.apache.org/jira/browse/PHOENIX-6966 > Project: Phoenix > Issue Type: Bug > Components: core >Affects Versions: 5.2.0, 5.1.3 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > > We always use the nin-encoded CQ when generating the empty cells. > This results in extra "_0" empty cell being generated when re-recrating > encoded qualifier Phoenix tables on existing HBase tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
