Call for Presentations, Community Over Code Asia 2023
You are receiving this message because you are subscribed to one more more developer mailing lists at the Apache Software Foundation. The call for presentations is now open at "https://apachecon.com/acasia2023/cfp.html;, and will be closed by Sunday, Jun 18th, 2023 11:59 PM GMT. The event will be held in Beijing, China, August 18-20, 2023. We are looking for presentations about anything relating to Apache Software Foundation projects, open-source governance, community, and software development. In particular, this year we are building content tracks around the following specific topics/projects: AI / Machine learning API / Microservice Community CloudNative Data Storage & Computing DataOps Data Lake & Data Warehouse OLAP & Data Analysis Performance Engineering Incubator IoT/IIoT Messaging RPC Streaming Workflow / Data Processing Web Server / Tomcat If your proposed presentation falls into one of these categories, please select that topic in the CFP entry form. Or select Others if it’s related to another topic or project area. Looking forward to hearing from you! Willem Jiang, and the Community Over Code planners
[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:
-
Fix Version/s: 5.1.4
(was: 5.1.3)
> Using a covered field in hinted non-covered indexed query fails
> ---
>
> Key: PHOENIX-6961
> URL: https://issues.apache.org/jira/browse/PHOENIX-6961
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.2.0, 5.1.3
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Critical
> Fix For: 5.2.0, 5.1.4
>
>
> 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}
>
--
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. I also suspect that this is not really specific to PostDDLMutationPlan, and all queries where a single chunk takes a lot of time would be affected. was: 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. I also suspect that this is not really specific to PostDDLMutationPlan, but > 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. > I also suspect that this is not really specific to PostDDLMutationPlan, and > all queries where a single chunk takes a lot of time would be affected. -- 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. I also suspect that this is not really specific to PostDDLMutationPlan, but was: 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. > 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. > I also suspect that this is not really specific to PostDDLMutationPlan, but -- This message was sent by Atlassian Jira (v8.20.10#820010)
