[jira] [Updated] (PHOENIX-6604) Index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6604:
---
Attachment: 6604.5.1.3
> Index not used for wildcard topN query on salted table
> --
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.2
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
> Attachments: 6604.5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PHOENIX-6604) Index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6604:
---
Summary: Index not used for wildcard topN query on salted table (was:
Local index not used for wildcard topN query on salted table)
> Index not used for wildcard topN query on salted table
> --
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.2
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (PHOENIX-6604) Local index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6604:
---
Description:
Just randomly came across this, playing with TPCH data.
{code:java}
CREATE TABLE lineitem (
orderkey bigint not null,
partkey bigint,
suppkey bigint,
linenumber integer not null,
quantity double,
extendedprice double,
discount double,
tax double,
returnflag varchar(1),
linestatus varchar(1),
shipdate date,
commitdate date,
receiptdate date,
shipinstruct varchar(25),
shipmode varchar(10),
comment varchar(44)
constraint pk primary key(orderkey, linenumber))
IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
Now:
{code:java}
> explain select * from lineitem order by shipdate limit 1;
+---+
| PLAN
|
+---+
| CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
OVER LI |
| SERVER TOP 1 ROW SORTED BY [SHIPDATE]
|
| CLIENT MERGE SORT
|
| CLIENT LIMIT 1
|
+---+
4 rows selected (6.525 seconds)
-- SAME COLUMNS!
> explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by shipdate
> limit 1;
+---+
|
|
+---+
| CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
|
| SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
0.DISCOUNT, |
| SERVER FILTER BY FIRST KEY ONLY
|
| SERVER 1 ROW LIMIT
|
| CLIENT MERGE SORT
|
| CLIENT 1 ROW LIMIT
|
+---+
6 rows selected (2.736 seconds){code}
was:
Just randomly came across this, playing with TPCH data.
{code:java}
CREATE TABLE lineitem (
orderkey bigint not null,
partkey bigint,
suppkey bigint,
linenumber integer not null,
quantity double,
extendedprice double,
discount double,
tax double,
returnflag varchar(1),
linestatus varchar(1),
shipdate date,
commitdate date,
receiptdate date,
shipinstruct varchar(25),
shipmode varchar(10),
comment varchar(44)
constraint pk primary key(orderkey, linenumber))
DATA_BLOCK_ENCODING='ROW_INDEX_V1', COMPRESSION='ZSTD', DISABLE_WAL=true,
IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
Now:
{code:java}
> explain select * from lineitem order by shipdate limit 1;
+---+
| PLAN
|
+---+
| CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
OVER LI |
| SERVER TOP 1 ROW SORTED BY [SHIPDATE]
|
| CLIENT MERGE SORT
|
| CLIENT LIMIT 1
|
+---+
4 rows selected (6.525 seconds)
-- SAME COLUMNS!
> explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by shipdate
> limit 1;
+---+
|
|
+---+
| CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
|
| SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
0.DISCOUNT, |
| SERVER FILTER BY FIRST KEY ONLY
|
| SERVER 1 ROW LIMIT
|
| CLIENT MERGE SORT
[jira] [Updated] (PHOENIX-6604) Local index not used for wildcard topN query on salted table
[
https://issues.apache.org/jira/browse/PHOENIX-6604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lars Hofhansl updated PHOENIX-6604:
---
Affects Version/s: 5.1.2
> Local index not used for wildcard topN query on salted table
>
>
> Key: PHOENIX-6604
> URL: https://issues.apache.org/jira/browse/PHOENIX-6604
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.1.2
>Reporter: Lars Hofhansl
>Priority: Major
> Fix For: 5.1.3
>
>
> Just randomly came across this, playing with TPCH data.
> {code:java}
> CREATE TABLE lineitem (
> orderkey bigint not null,
> partkey bigint,
> suppkey bigint,
> linenumber integer not null,
> quantity double,
> extendedprice double,
> discount double,
> tax double,
> returnflag varchar(1),
> linestatus varchar(1),
> shipdate date,
> commitdate date,
> receiptdate date,
> shipinstruct varchar(25),
> shipmode varchar(10),
> comment varchar(44)
> constraint pk primary key(orderkey, linenumber))
> DATA_BLOCK_ENCODING='ROW_INDEX_V1', COMPRESSION='ZSTD', DISABLE_WAL=true,
> IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
> Now:
> {code:java}
> > explain select * from lineitem order by shipdate limit 1;
> +---+
> | PLAN
> |
> +---+
> | CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
> OVER LI |
> | SERVER TOP 1 ROW SORTED BY [SHIPDATE]
> |
> | CLIENT MERGE SORT
> |
> | CLIENT LIMIT 1
> |
> +---+
> 4 rows selected (6.525 seconds)
> -- SAME COLUMNS!
> > explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> > EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> > RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by
> > shipdate limit 1;
> +---+
> |
> |
> +---+
> | CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
> |
> | SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
> 0.DISCOUNT, |
> | SERVER FILTER BY FIRST KEY ONLY
> |
> | SERVER 1 ROW LIMIT
> |
> | CLIENT MERGE SORT
> |
> | CLIENT 1 ROW LIMIT
> |
> +---+
> 6 rows selected (2.736 seconds){code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (PHOENIX-6604) Local index not used for wildcard topN query on salted table
Lars Hofhansl created PHOENIX-6604:
--
Summary: Local index not used for wildcard topN query on salted
table
Key: PHOENIX-6604
URL: https://issues.apache.org/jira/browse/PHOENIX-6604
Project: Phoenix
Issue Type: Bug
Reporter: Lars Hofhansl
Fix For: 5.1.3
Just randomly came across this, playing with TPCH data.
{code:java}
CREATE TABLE lineitem (
orderkey bigint not null,
partkey bigint,
suppkey bigint,
linenumber integer not null,
quantity double,
extendedprice double,
discount double,
tax double,
returnflag varchar(1),
linestatus varchar(1),
shipdate date,
commitdate date,
receiptdate date,
shipinstruct varchar(25),
shipmode varchar(10),
comment varchar(44)
constraint pk primary key(orderkey, linenumber))
DATA_BLOCK_ENCODING='ROW_INDEX_V1', COMPRESSION='ZSTD', DISABLE_WAL=true,
IMMUTABLE_ROWS=true,SALT_BUCKETS=4;{code}
Now:
{code:java}
> explain select * from lineitem order by shipdate limit 1;
+---+
| PLAN
|
+---+
| CLIENT 199-CHUNK 8859938 ROWS 2044738843 BYTES PARALLEL 199-WAY FULL SCAN
OVER LI |
| SERVER TOP 1 ROW SORTED BY [SHIPDATE]
|
| CLIENT MERGE SORT
|
| CLIENT LIMIT 1
|
+---+
4 rows selected (6.525 seconds)
-- SAME COLUMNS!
> explain select ORDERKEY, PARTKEY, SUPPKEY, LINENUMBER, QUANTITY,
> EXTENDEDPRICE, DISCOUNT, TAX, RETURNFLAG, LINESTATUS, SHIPDATE, COMMITDATE,
> RECEIPTDATE, SHIPINSTRUCT, SHIPMODE, COMMENT from lineitem order by shipdate
> limit 1;
+---+
|
|
+---+
| CLIENT 4-CHUNK 4 ROWS 204 BYTES PARALLEL 4-WAY RANGE SCAN OVER LINEITEM [1]
|
| SERVER MERGE [0.PARTKEY, 0.SUPPKEY, 0.QUANTITY, 0.EXTENDEDPRICE,
0.DISCOUNT, |
| SERVER FILTER BY FIRST KEY ONLY
|
| SERVER 1 ROW LIMIT
|
| CLIENT MERGE SORT
|
| CLIENT 1 ROW LIMIT
|
+---+
6 rows selected (2.736 seconds){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (PHOENIX-6603) Create SYSTEM.TRANSFORM table
Gokcen Iskender created PHOENIX-6603: Summary: Create SYSTEM.TRANSFORM table Key: PHOENIX-6603 URL: https://issues.apache.org/jira/browse/PHOENIX-6603 Project: Phoenix Issue Type: Sub-task Reporter: Gokcen Iskender SYSTEM.TRANSFORM is a table for bookkeeping the transform process -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PHOENIX-6373) Schema changes that require table re-writes can be supported (Online data format changes)
[ https://issues.apache.org/jira/browse/PHOENIX-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-6373: - Description: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link: [https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] was: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link: : https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing > Schema changes that require table re-writes can be supported (Online data > format changes) > - > > Key: PHOENIX-6373 > URL: https://issues.apache.org/jira/browse/PHOENIX-6373 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > > Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain > changes to the schema. For example, changing certain table properties like > TTL and immutability, adding nullable columns/dropping non-pk columns are > allowed as well as certain index state changes. All of the allowed changes > don’t require the table to be re-written. As soon as the ALTER command > returns, most of the changes became available immediately (eg. index disable, > TTL) but some of them might take some time and the syntax lets you to specify > async (eg. Rebuild index) and depending on the client cache settings, some > changes never make it to the client (eg. select * that run from a client > never seeing the new column since its schema cache is not updated). > If the user wants to change the schema properties that require table > re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to > change some of the table schemas and attributes, such changing the row key > (primary keys), the type of a column, the table storage format, the column > encoding, etc. There is no way to make this changes with no or very minimal > service interruption. > Design doc link: > [https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PHOENIX-6373) Schema changes that require table re-writes can be supported (Online data format changes)
[ https://issues.apache.org/jira/browse/PHOENIX-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-6373: - Description: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link: : https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing was: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link is [here|: https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] > Schema changes that require table re-writes can be supported (Online data > format changes) > - > > Key: PHOENIX-6373 > URL: https://issues.apache.org/jira/browse/PHOENIX-6373 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > > Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain > changes to the schema. For example, changing certain table properties like > TTL and immutability, adding nullable columns/dropping non-pk columns are > allowed as well as certain index state changes. All of the allowed changes > don’t require the table to be re-written. As soon as the ALTER command > returns, most of the changes became available immediately (eg. index disable, > TTL) but some of them might take some time and the syntax lets you to specify > async (eg. Rebuild index) and depending on the client cache settings, some > changes never make it to the client (eg. select * that run from a client > never seeing the new column since its schema cache is not updated). > If the user wants to change the schema properties that require table > re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to > change some of the table schemas and attributes, such changing the row key > (primary keys), the type of a column, the table storage format, the column > encoding, etc. There is no way to make this changes with no or very minimal > service interruption. > Design doc link: : > https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PHOENIX-6373) Schema changes that require table re-writes can be supported (Online data format changes)
[ https://issues.apache.org/jira/browse/PHOENIX-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-6373: - Description: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link is [#: https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] was: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. > Schema changes that require table re-writes can be supported (Online data > format changes) > - > > Key: PHOENIX-6373 > URL: https://issues.apache.org/jira/browse/PHOENIX-6373 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > > Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain > changes to the schema. For example, changing certain table properties like > TTL and immutability, adding nullable columns/dropping non-pk columns are > allowed as well as certain index state changes. All of the allowed changes > don’t require the table to be re-written. As soon as the ALTER command > returns, most of the changes became available immediately (eg. index disable, > TTL) but some of them might take some time and the syntax lets you to specify > async (eg. Rebuild index) and depending on the client cache settings, some > changes never make it to the client (eg. select * that run from a client > never seeing the new column since its schema cache is not updated). > If the user wants to change the schema properties that require table > re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to > change some of the table schemas and attributes, such changing the row key > (primary keys), the type of a column, the table storage format, the column > encoding, etc. There is no way to make this changes with no or very minimal > service interruption. > Design doc link is [#: > https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (PHOENIX-6373) Schema changes that require table re-writes can be supported (Online data format changes)
[ https://issues.apache.org/jira/browse/PHOENIX-6373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gokcen Iskender updated PHOENIX-6373: - Description: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link is [here|: https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] was: Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain changes to the schema. For example, changing certain table properties like TTL and immutability, adding nullable columns/dropping non-pk columns are allowed as well as certain index state changes. All of the allowed changes don’t require the table to be re-written. As soon as the ALTER command returns, most of the changes became available immediately (eg. index disable, TTL) but some of them might take some time and the syntax lets you to specify async (eg. Rebuild index) and depending on the client cache settings, some changes never make it to the client (eg. select * that run from a client never seeing the new column since its schema cache is not updated). If the user wants to change the schema properties that require table re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to change some of the table schemas and attributes, such changing the row key (primary keys), the type of a column, the table storage format, the column encoding, etc. There is no way to make this changes with no or very minimal service interruption. Design doc link is [#: https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] > Schema changes that require table re-writes can be supported (Online data > format changes) > - > > Key: PHOENIX-6373 > URL: https://issues.apache.org/jira/browse/PHOENIX-6373 > Project: Phoenix > Issue Type: Improvement >Reporter: Gokcen Iskender >Assignee: Gokcen Iskender >Priority: Major > > Today, using ALTER TABLE or ALTER INDEX commands, the user can make certain > changes to the schema. For example, changing certain table properties like > TTL and immutability, adding nullable columns/dropping non-pk columns are > allowed as well as certain index state changes. All of the allowed changes > don’t require the table to be re-written. As soon as the ALTER command > returns, most of the changes became available immediately (eg. index disable, > TTL) but some of them might take some time and the syntax lets you to specify > async (eg. Rebuild index) and depending on the client cache settings, some > changes never make it to the client (eg. select * that run from a client > never seeing the new column since its schema cache is not updated). > If the user wants to change the schema properties that require table > re-writes, it is blocked and ALTER fails. Phoenix lacks of the ability to > change some of the table schemas and attributes, such changing the row key > (primary keys), the type of a column, the table storage format, the column > encoding, etc. There is no way to make this changes with no or very minimal > service interruption. > Design doc link is [here|: > https://docs.google.com/document/d/1D24zRETMEetXvc3MSZj9WKYeUnooQX5BLv6gSDEmwfk/edit?usp=sharing] -- This message was sent by Atlassian Jira (v8.20.1#820001)
