华为云用户手册

对*-LIST二级分区表分割二级分区 使用ALTER TABLE SPLIT SUBPARTITION可以对*-LIST二级分区表分割二级分区。 例如，假设*-LIST二级分区表hash_list_sales的二级分区product2_channel2的定义范围为DEFAULT。可以指定分割点将其分割为两个分区，并更新Global索引。 ALTER TABLE hash_list_sales SPLIT SUBPARTITION product2_channel2 VALUES ('6', '7', '8', '9') INTO ( SUBPARTITION product2_channel2_p1, --第一个分区范围是('6', '7', '8', '9') SUBPARTITION product2_channel2_p2 --第二个分区范围是DEFAULT ) UPDATE GLOBAL INDEX; 或者，不指定分割点，将分区product2_channel2分割为多个分区，并更新Global索引。 ALTER TABLE hash_list_sales SPLIT SUBPARTITION product2_channel2 INTO ( SUBPARTITION product2_channel2_p1 VALUES ('6', '7', '8'), SUBPARTITION product2_channel2_p2 VALUES ('9', '10'), SUBPARTITION product2_channel2_p3 --第三个分区范围是DEFAULT ) UPDATE GLOBAL INDEX; 又或者，通过指定分区值而不是指定分区名来分割分区。 ALTER TABLE hash_list_sales SPLIT SUBPARTITION FOR (1200, '6') VALUES ('6', '7', '8', '9') INTO ( SUBPARTITION product2_channel2_p1, --第一个分区范围是('6', '7', '8', '9') SUBPARTITION product2_channel2_p2 --第二个分区范围是DEFAULT ) UPDATE GLOBAL INDEX; 若对DEFAULT分区进行分割，前面几个分区不能申明DEFAULT范围，最后一个分区会继承DEFAULT分区范围。 父主题： 分割分区

使用Astore的优势 Astore没有回滚段，而Ustore有回滚段。对于Ustore来说，回滚段是非常重要的，回滚段损坏会导致数据丢失甚至数据库无法启动的严重问题。且Ustore恢复时同步需要Redo和Undo。由于Astore没有回滚段，旧数据都是记录在原先的文件中，所以当数据库异常crash后，恢复时，不会像Ustore数据库那样进行复杂的恢复。 由于旧的数据是直接记录在数据文件中，而不是回滚段中，所以不会经常报Snapshot Too Old错误。 回滚可以很快完成，因为回滚并不删除数据。 回滚时很复杂，在事务回滚时必须清理该事务所进行的修改，插入的记录要删除，更新的记录要更新回来，同时回滚的过程也会再次产生大量的Redo日志。 WAL日志要简单一些，仅需要记录数据文件的变化，不需要记录回滚段的变化。 支持回收站（闪回DROP、闪回Truncate）功能。

DQL/DML-DDL同分区并发 GaussDB不支持同分区的DQL/DML-DDL并发，后触发业务会被先触发业务阻塞。 原则上，不建议用户在进行分区DDL时，同时对该分区进行DQL/DML操作，因为目标分区存在一个状态的突变过程，可能会导致业务的查询结果不符合预期。 如果由于业务模型不合理、无法剪枝等场景导致的DQL/DML和DDL作用分区有重叠时，考虑两种场景： 场景一：先触发DQL/DML，再触发DDL。DDL会被阻塞，等DQL/DML提交后再进行。 场景二：先触发DDL，再触发DQL/DML。DQL/DML会被阻塞，等DDL提交后再进行，由于分区元信息发生了变更，可能导致预期不合理。为了保证数据一致性，预期结果按照如下规则制定。 在DQL/DML业务期间，如果对执行DQL/DML操作的分区，同时做多次分区DDL操作，有低概率出现报错，报错原因：分区找不到，分区已经被DDL删除。 ADD分区 ADD分区会产生一个新的分区，这个新分区对期间触发的DQL/DML操作均是不可见的，无阻塞期。 DROP分区 DROP分区会将已有分区进行删除，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后跳过对该分区的处理。 TRUNCATE分区 TRUNCATE分区会将已有分区清空数据，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后继续对该分区进行处理。 注意期间触发的目标分区查询是查不到数据的，因为TRUNCATE操作提交后目标分区中不存有任何数据。 EXCHANGE分区 EXCHANGE分区会将一个已有分区与普通表进行交换，期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后继续对该分区进行处理，该分区的实际数据对应原普通表。 例外：如果分区表上存在GLOBAL索引，EXCHANGE命令带来UPDATE GLOBAL INDEX子句，且期间触发的分区表查询使用了GLOBAL索引，由于无法查询到交换后分区上的数据，在阻塞完成后查询业务会报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations EXCHANGE PARTITION SPLIT分区 SPLIT分区会将一个分区分割为多个分区，即使其中一个新分区与旧分区名字相同，也视为不同的分区。期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后业务报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations SPLIT PARTITION MERGE分区 MERGE分区会将多个分区合并为一个分区，如果合并后的分区与其中一个旧分区A名字相同，逻辑上视为相同分区。期间触发的目标分区DQL/DML操作会被阻塞，阻塞完成后，根据目标分区类型判断，如果目标分区是旧分区A，则作用于新分区；如果目标分区为其他旧分区，则业务报错。 ERROR: partition xxxxxx does not exist on relation "xxxxxx" DETAIL: this partition may have already been dropped by cocurrent DDL operations MERGE PARTITION RENAME分区 RENAME分区不会变更分区结构信息，期间触发的DQL/DML操作不会出现任何异常，但会被阻塞，直到RENAME操作提交。 MOVE分区 MOVE分区不会变更分区结构信息，期间触发的DQL/DML操作不会出现任何异常，但会被阻塞，直到MOVE操作提交。

使用示例 gaussdb=# DROP TABLE IF EXISTS "public".flashtest; NOTICE: table "flashtest" does not exist, skipping DROP TABLE --创建表flashtest gaussdb=# CREATE TABLE "public".flashtest (col1 INT,col2 TEXT) WITH(storage_type=ustore); CREATE TABLE --查询csn gaussdb=# SELECT int8in(xidout(next_csn)) FROM gs_get_next_xid_csn(); int8in ---------- 79352065 (1 rows) --查询当前时间戳 gaussdb=# SELECT now(); now ------------------------------- 2023-09-13 19:46:34.102863+08 (1 row) gaussdb=# SELECT * FROM flashtest; col1 | col2 ------+------ (0 rows) --插入数据 gaussdb=# INSERT INTO flashtest VALUES(1,'INSERT1'),(2,'INSERT2'),(3,'INSERT3'),(4,'INSERT4'),(5,'INSERT5'),(6,'INSERT6'); INSERT 0 6 gaussdb=# SELECT * FROM flashtest; col1 | col2 ------+--------- 3 | INSERT3 6 | INSERT6 1 | INSERT1 2 | INSERT2 4 | INSERT4 5 | INSERT5 (6 rows) --闪回表至特定的时间戳 gaussdb=# TIMECAPSULE TABLE flashtest TO TIMESTAMP to_timestamp ('2023-09-13 19:52:21.551028', 'YYYY-MM-DD HH24:MI:SS.FF'); TimeCapsule Table gaussdb=# SELECT * FROM flashtest; col1 | col2 ------+------ (0 rows) gaussdb=# SELECT now(); now ------------------------------- 2023-09-13 19:54:00.641506+08 (1 row) --插入数据 gaussdb=# INSERT INTO flashtest VALUES(1,'INSERT1'),(2,'INSERT2'),(3,'INSERT3'),(4,'INSERT4'),(5,'INSERT5'),(6,'INSERT6'); INSERT 0 6 gaussdb=# SELECT * FROM flashtest; col1 | col2 ------+--------- 3 | INSERT3 6 | INSERT6 1 | INSERT1 2 | INSERT2 4 | INSERT4 5 | INSERT5 (6 rows) --闪回表至特定的时间戳 gaussdb=# TIMECAPSULE TABLE flashtest TO TIMESTAMP '2023-09-13 19:54:00.641506'; TimeCapsule Table gaussdb=# SELECT * FROM flashtest; col1 | col2 ------+------ (0 rows) gaussdb=# DROP TABLE IF EXISTS "public".flashtest; DROP TABLE

开启/关闭二级列表分区自动扩展 使用ALTER TABLE SET SUBPARTITIONING可以开启/关闭二级列表分区自动扩展功能。 例如： 开启二级列表分区自动扩展。 gaussdb=# CREATE TABLE range_list (c1 int, c2 int) PARTITION BY RANGE (c1) SUBPARTITION BY LIST (c2) ( PARTITION p1 VALUES LESS THAN (5) ( SUBPARTITION sp11 VALUES (1, 2, 3), SUBPARTITION sp12 VALUES (4, 5, 6) ), PARTITION p2 VALUES LESS THAN (10) ( SUBPARTITION sp21 VALUES (1, 2, 3), SUBPARTITION sp22 VALUES (4, 5, 6) ) ); gaussdb=# ALTER TABLE range_list SET SUBPARTITIONING AUTOMATIC; 开启二级列表分区自动扩展要求二级分区中不能存在分区键值为DEFAULT的分区。 关闭二级列表分区自动扩展。 gaussdb=# ALTER TABLE range_list SET SUBPARTITIONING MANUAL; --清理示例 gaussdb=# DROP TABLE range_list; 父主题： 开启/关闭分区自动扩展

注意事项及约束条件 当分区扫描路径为Index/Index Only时，才支持Merge Append执行机制。 当分区剪枝结果大于1时，才支持Merge Append执行机制。 当分区索引全部有效且为btree索引时，才支持Merge Append执行机制。 当SQL含有Limit子句时，才支持Merge Append执行机制。 当分区扫描时如果存在Filter，不支持Merge Append执行机制。 当GUC参数sql_beta_feature = 'disable_merge_append_partition'时，不再生成Merge Append路径。

场景描述 当对分区表进行全局排序时，通常SQL引擎的实现方式是先通过Partition Iterator + PartitionScan对分区表做全量扫描，然后进行Sort排序操作，这样难以利用数据分区分治的算法思想进行全局排序，假如ORDER BY排序列包含索引，本身局部有序的前提条件则无法利用。针对这类问题，目前分区表支持分区归并排序执行策略，利用Merge Append的执行机制改进分区表的排序机制。

对二级分区表交换二级分区 使用ALTER TABLE EXCHANGE SUBPARTITION可以对二级分区表交换二级分区。 例如，通过指定分区名将二级分区表range_list_sales的二级分区date_202001_channel1和普通表exchange_sales进行交换，不进行分区键校验，并更新Global索引。 ALTER TABLE range_list_sales EXCHANGE SUBPARTITION (date_202001_channel1) WITH TABLE exchange_sales WITHOUT VALIDATION UPDATE GLOBAL INDEX; 或者，通过指定分区值将二级分区表range_list_sales中('2020-01-08', '0')所对应的二级分区和普通表exchange_sales进行交换，进行分区校验并将不满足目标分区约束的数据插入到分区表的其他分区中。由于不带UPDATE GLOBAL INDEX子句，执行该命令后Global索引会失效。 ALTER TABLE range_list_sales EXCHANGE SUBPARTITION FOR ('2020-01-08', '0') WITH TABLE exchange_sales WITH VALIDATION VERBOSE; 不支持对二级分区表的一级分区交换分区。 父主题： 交换分区

注意事项及约束条件 GUC参数partition_iterator_elimination开启后，且优化器剪枝结果只有一个分区时，目标场景优化才能生效。 消除Partition Iterator算子不支持二级分区表。 支持cplan，支持部分gplan场景，如分区键a = $1（即优化器阶段可以剪枝到一个分区的场景）。 支持SeqScan、Indexscan、Indexonlyscan、Bitmapscan、RowToVec、Tidscan算子。 支持行存，astore/ustore存储引擎，支持SQLBypass。

场景描述 在当前分区表架构中，执行器通过Partition Iterator算子去迭代访问每一个分区。当分区剪枝结果只有一个分区时，Partition Iterator算子已经失去了迭代器的作用，在此情况下消除Partition Iterator算子，可以避免执行时一些不必要的开销。由于执行器的PIPELINE架构，Partition Iterator算子会重复执行，在数据量较大的场景下消除Partition Iterator算子的收益十分可观。

示例 创建分区表并插入数据 gaussdb=# CREATE TABLE t1_range_int ( c1 INT, c2 INT, c3 INT, c4 INT ) PARTITION BY RANGE(c1) ( PARTITION range_p00 VALUES LESS THAN(10), PARTITION range_p01 VALUES LESS THAN(20), PARTITION range_p02 VALUES LESS THAN(30), PARTITION range_p03 VALUES LESS THAN(40), PARTITION range_p04 VALUES LESS THAN(50) ); gaussdb=# INSERT INTO t1_range_int SELECT v,v,v,v FROM generate_series(0, 49) AS v; 级联收集统计信息 gaussdb=# ANALYZE t1_range_int WITH ALL; 查看分区级统计信息 gaussdb=# SELECT relname, parttype, relpages, reltuples FROM pg_partition WHERE parentid=(SELECT oid FROM pg_class WHERE relname='t1_range_int') ORDER BY relname; relname | parttype | relpages | reltuples --------------+----------+----------+----------- range_p00 | p | 1 | 10 range_p01 | p | 1 | 10 range_p02 | p | 1 | 10 range_p03 | p | 1 | 10 range_p04 | p | 1 | 10 t1_range_int | r | 0 | 0 (6 rows) gaussdb=# SELECT schemaname,tablename,partitionname,subpartitionname,attname,inherited,null_frac,avg_width,n_distinct,n_dndistinct,most_common_vals,most_common_freqs,histogram_bounds FROM pg_stats WHERE tablename='t1_range_int' ORDER BY tablename, partitionname, attname; schemaname | tablename | partitionname | subpartitionname | attname | inherited | null_frac | avg_width | n_distinct | n_dndistinct | most_common_vals | most_common_freqs | histogram_bounds ------------+--------------+---------------+------------------+---------+-----------+-----------+-----------+------------+--------------+------------------+-------------------+---------------------------------------------------------------------------------------------- ------------------------------------------------- public | t1_range_int | range_p00 | | c1 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9} public | t1_range_int | range_p00 | | c2 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9} public | t1_range_int | range_p00 | | c3 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9} public | t1_range_int | range_p00 | | c4 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9} public | t1_range_int | range_p01 | | c1 | f | 0 | 4 | -1 | 0 | | | {10,11,12,13,14,15,16,17,18,19} public | t1_range_int | range_p01 | | c2 | f | 0 | 4 | -1 | 0 | | | {10,11,12,13,14,15,16,17,18,19} public | t1_range_int | range_p01 | | c3 | f | 0 | 4 | -1 | 0 | | | {10,11,12,13,14,15,16,17,18,19} public | t1_range_int | range_p01 | | c4 | f | 0 | 4 | -1 | 0 | | | {10,11,12,13,14,15,16,17,18,19} public | t1_range_int | range_p02 | | c1 | f | 0 | 4 | -1 | 0 | | | {20,21,22,23,24,25,26,27,28,29} public | t1_range_int | range_p02 | | c2 | f | 0 | 4 | -1 | 0 | | | {20,21,22,23,24,25,26,27,28,29} public | t1_range_int | range_p02 | | c3 | f | 0 | 4 | -1 | 0 | | | {20,21,22,23,24,25,26,27,28,29} public | t1_range_int | range_p02 | | c4 | f | 0 | 4 | -1 | 0 | | | {20,21,22,23,24,25,26,27,28,29} public | t1_range_int | range_p03 | | c1 | f | 0 | 4 | -1 | 0 | | | {30,31,32,33,34,35,36,37,38,39} public | t1_range_int | range_p03 | | c2 | f | 0 | 4 | -1 | 0 | | | {30,31,32,33,34,35,36,37,38,39} public | t1_range_int | range_p03 | | c3 | f | 0 | 4 | -1 | 0 | | | {30,31,32,33,34,35,36,37,38,39} public | t1_range_int | range_p03 | | c4 | f | 0 | 4 | -1 | 0 | | | {30,31,32,33,34,35,36,37,38,39} public | t1_range_int | range_p04 | | c1 | f | 0 | 4 | -1 | 0 | | | {40,41,42,43,44,45,46,47,48,49} public | t1_range_int | range_p04 | | c2 | f | 0 | 4 | -1 | 0 | | | {40,41,42,43,44,45,46,47,48,49} public | t1_range_int | range_p04 | | c3 | f | 0 | 4 | -1 | 0 | | | {40,41,42,43,44,45,46,47,48,49} public | t1_range_int | range_p04 | | c4 | f | 0 | 4 | -1 | 0 | | | {40,41,42,43,44,45,46,47,48,49} public | t1_range_int | | | c1 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33, 34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49} public | t1_range_int | | | c2 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33, 34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49} public | t1_range_int | | | c3 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33, 34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49} public | t1_range_int | | | c4 | f | 0 | 4 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33, 34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49} (24 rows) 生成多列数据的分区级统计信息 gaussdb=# ALTER TABLE t1_range_int ADD STATISTICS ((c2, c3)); gaussdb=# ANALYZE t1_range_int WITH ALL; 查看多列数据的分区级统计信息 gaussdb=# SELECT schemaname,tablename,partitionname,subpartitionname,attname,inherited,null_frac,avg_width,n_distinct,n_dndistinct,most_common_vals,most_common_freqs,histogram_bounds FROM pg_ext_stats WHERE tablename='t1_range_int' ORDER BY tablename,partitionname,attname; schemaname | tablename | partitionname | subpartitionname | attname | inherited | null_frac | avg_width | n_distinct | n_dndistinct | most_common_vals | most_common_freqs | histogram_bounds ------------+--------------+---------------+------------------+---------+-----------+-----------+-----------+------------+--------------+------------------+-------------------+------------------ public | t1_range_int | range_p00 | | 2 3 | f | 0 | 8 | -1 | 0 | | | public | t1_range_int | range_p01 | | 2 3 | f | 0 | 8 | -1 | 0 | | | public | t1_range_int | range_p02 | | 2 3 | f | 0 | 8 | -1 | 0 | | | public | t1_range_int | range_p03 | | 2 3 | f | 0 | 8 | -1 | 0 | | | public | t1_range_int | range_p04 | | 2 3 | f | 0 | 8 | -1 | 0 | | | public | t1_range_int | | | 2 3 | f | 0 | 8 | -1 | 0 | | | (6 rows) 创建表达式索引并生成对应的分区级统计信息 gaussdb=# CREATE INDEX t1_range_int_index ON t1_range_int(text(c1)) LOCAL; gaussdb=# ANALYZE t1_range_int WITH ALL; 查看表达式索引的分区级统计信息 gaussdb=# SELECT schemaname,tablename,partitionname,subpartitionname,attname,inherited,null_frac,avg_width,n_distinct,n_dndistinct,most_common_vals,most_common_freqs,histogram_bounds FROM pg_stats WHERE tablename='t1_range_int_index' ORDER BY tablename,partitionname,attname; schemaname | tablename | partitionname | subpartitionname | attname | inherited | null_frac | avg_width | n_distinct | n_dndistinct | most_common_vals | most_common_freqs | histogram_bounds ------------+--------------------+--------------------+------------------+---------+-----------+-----------+-----------+------------+--------------+------------------+-------------------+----------------------------------------------------------------------------------- ------------------------------------------------------------ public | t1_range_int_index | range_p00_text_idx | | text | f | 0 | 5 | -1 | 0 | | | {0,1,2,3,4,5,6,7,8,9} public | t1_range_int_index | range_p01_text_idx | | text | f | 0 | 6 | -1 | 0 | | | {10,11,12,13,14,15,16,17,18,19} public | t1_range_int_index | range_p02_text_idx | | text | f | 0 | 6 | -1 | 0 | | | {20,21,22,23,24,25,26,27,28,29} public | t1_range_int_index | range_p03_text_idx | | text | f | 0 | 6 | -1 | 0 | | | {30,31,32,33,34,35,36,37,38,39} public | t1_range_int_index | range_p04_text_idx | | text | f | 0 | 6 | -1 | 0 | | | {40,41,42,43,44,45,46,47,48,49} public | t1_range_int_index | | | text | f | 0 | 5 | -1 | 0 | | | {0,1,10,11,12,13,14,15,16,17,18,19,2,20,21,22,23,24,25,26,27,28,29,3,30,31,32,33,3 4,35,36,37,38,39,4,40,41,42,43,44,45,46,47,48,49,5,6,7,8,9} (6 rows) 删除分区表 gaussdb=# DROP TABLE t1_range_int;

向列表分区表新增分区 使用ALTER TABLE ADD PARTITION可以在列表分区表中新增分区，新增分区的枚举值不能与已有的任一个分区的枚举值重复。 例如，对列表分区表list_sales新增一个分区。 ALTER TABLE list_sales ADD PARTITION channel5 VALUES ('X') TABLESPACE tb1; 当列表分区表有DEFAULT分区时，无法新增分区。可以使用ALTER TABLE SPLIT PARTITION命令分割分区。 父主题： 新增分区

Local索引分区重建/不可用 使用ALTER INDEX PARTITION可以设置Local索引分区是否可用。 使用ALTER TABLE MODIFY PARTITION可以设置分区表上指定分区的所有索引分区是否可用。这个语法如果作用于二级分区表的一级分区，数据库会将这个一级分区下的所有二级分区均进行设置。 使用ALTER TABLE MODIFY SUBPARTITION可以设置二级分区表上指定二级分区的所有索引分区是否可用。 例如，假设分区表range_sales上存在两张Local索引range_sales_idx1和range_sales_idx2，假设其在分区date_202001上对应的索引分区名分别为range_sales_idx1_part1和range_sales_idx2_part1。 下面给出了维护分区表分区索引的语法： 可以通过如下命令设置分区date_202001上的所有索引分区均不可用。 ALTER TABLE range_sales MODIFY PARTITION date_202001 UNUSABLE LOCAL INDEXES; 或者通过如下命令单独设置分区date_202001上的索引分区range_sales_idx1_part1不可用。 ALTER INDEX range_sales_idx1 MODIFY PARTITION range_sales_idx1_part1 UNUSABLE; 可以通过如下命令重建分区date_202001上的所有索引分区。 ALTER TABLE range_sales MODIFY PARTITION date_202001 REBUILD UNUSABLE LOCAL INDEXES; 或者通过如下命令单独重建分区date_202001上的索引分区range_sales_idx1_part1。 ALTER INDEX range_sales_idx1 REBUILD PARTITION range_sales_idx1_part1; 假设二级分区表list_range_sales上存在两张Local索引list_range_sales_idx1和list_range_sales_idx2，表下有一级分区channel1，其下属二级分区有channel1_product1、channel1_product2、channel1_product3，二级分区channel1_product1上对应的索引分区名分别为channel1_product1_idx1和channel1_product1_idx2。 下面给出了维护二级分区表一级分区索引的语法： 可以通过如下命令设置分区channel1下属二级分区的所有索引分区均不可用，包括二级分区channel1_product1、channel1_product2、channel1_product3。 ALTER TABLE list_range_sales MODIFY PARTITION channel1 UNUSABLE LOCAL INDEXES; 可以通过如下命令重建分区channel1下属二级分区的所有索引分区。 ALTER TABLE list_range_sales MODIFY PARTITION channel1 REBUILD UNUSABLE LOCAL INDEXES; 下面给出了维护二级分区表二级分区索引的语法： 可以通过如下命令单独设置二级分区channel1_product1上的所有索引分区均不可用。 ALTER TABLE list_range_sales MODIFY SUBPARTITION channel1_product1 UNUSABLE LOCAL INDEXES; 可以通过如下命令重建二级分区channel1_product1上的所有索引分区。 ALTER TABLE list_range_sales MODIFY SUBPARTITION channel1_product1 REBUILD UNUSABLE LOCAL INDEXES; 或者通过如下命令单独设置二级分区channel1_product1上的索引分区channel1_product1_idx1不可用。 ALTER INDEX list_range_sales_idx1 MODIFY PARTITION channel1_product1_idx1 UNUSABLE; 通过如下命令单独重建二级分区channel1_product1上的索引分区channel1_product1_idx1。 ALTER INDEX list_range_sales_idx1 REBUILD PARTITION channel1_product1_idx1; 父主题： 分区表索引重建/不可用

示例 -- 修改表的默认类型 gaussdb=# set enable_default_ustore_table=off; --准备数据。 gaussdb=# CREATE TABLE t1(c1 int, c2 int); gaussdb=# INSERT INTO t1 VALUES(1, 1); gaussdb=# INSERT INTO t1 VALUES(2, 2); --创建增量物化视图。 gaussdb=# CREATE INCREMENTAL MATERIALIZED VIEW mv AS SELECT * FROM t1; CREATE MATERIALIZED VIEW --插入数据。 gaussdb=# INSERT INTO t1 VALUES(3, 3); INSERT 0 1 --增量刷新物化视图。 gaussdb=# REFRESH INCREMENTAL MATERIALIZED VIEW mv; REFRESH MATERIALIZED VIEW --查询物化视图结果。 gaussdb=# SELECT * FROM mv; c1 | c2 ----+---- 1 | 1 2 | 2 3 | 3 (3 rows) --插入数据。 gaussdb=# INSERT INTO t1 VALUES(4, 4); INSERT 0 1 --全量刷新物化视图。 gaussdb=# REFRESH MATERIALIZED VIEW mv; REFRESH MATERIALIZED VIEW --查询物化视图结果。 gaussdb=# select * from mv; c1 | c2 ----+---- 1 | 1 2 | 2 3 | 3 4 | 4 (4 rows) --删除物化视图，删除表。 gaussdb=# DROP MATERIALIZED VIEW mv; DROP MATERIALIZED VIEW gaussdb=# DROP TABLE t1; DROP TABLE

语法格式 创建增量物化视图 CREATE INCREMENTAL MATERIALIZED VIEW view_name AS query; 全量刷新物化视图 REFRESH MATERIALIZED VIEW view_name; 增量刷新物化视图 REFRESH INCREMENTAL MATERIALIZED VIEW view_name; 删除物化视图 DROP MATERIALIZED VIEW view_name; 查询物化视图 SELECT * FROM view_name;

在线校验功能 在线校验是Ustore特有的，在运行过程中可以有效预防页面因编码逻辑错误导致的逻辑损坏，默认开启UPAGE:UBTREE:UNDO三个模块校验。业务现网请保持开启，性能场景除外。 关闭： gs_guc reload -Z datanode -N all -I all -c "ustore_attr=''" 打开： gs_guc reload -Z datanode -N all -I all -c "ustore_attr='ustore_verify_level=fast;ustore_verify_module=upage:ubtree:undo'" 父主题： Ustore的最佳实践

向二级分区表新增一级分区 使用ALTER TABLE ADD PARTITION可以在二级分区表中新增一个一级分区，这个行为可以作用在一级分区策略为RANGE或者LIST的情况。如果这个新增一级分区下申明了二级分区定义，则数据库会根据定义创建对应的二级分区；如果这个新增一级分区下没有申明二级分区定义，则数据库会自动创建一个默认的二级分区。 例如，对二级分区表range_list_sales新增一个一级分区，并在下面创建四个二级分区。 ALTER TABLE range_list_sales ADD PARTITION date_202005 VALUES LESS THAN ('2020-06-01') TABLESPACE tb1 ( SUBPARTITION date_202005_channel1 VALUES ('0', '1', '2'), SUBPARTITION date_202005_channel2 VALUES ('3', '4', '5') TABLESPACE tb2, SUBPARTITION date_202005_channel3 VALUES ('6', '7'), SUBPARTITION date_202005_channel4 VALUES ('8', '9') ); 或者对二级分区表range_list_sales只进行新增一级分区操作。 ALTER TABLE range_list_sales ADD PARTITION date_202005 VALUES LESS THAN ('2020-06-01') TABLESPACE tb1; 上面这种行为与如下SQL语句等价。 ALTER TABLE range_list_sales ADD PARTITION date_202005 VALUES LESS THAN ('2020-06-01') TABLESPACE tb1 ( SUBPARTITION date_202005_channel1 VALUES (DEFAULT) ); 当二级分区表的一级分区策略为HASH时，不支持通过ALTER TABLE ADD PARTITION命令新增一级分区。 父主题： 新增分区

空间管理 Undo子系统依赖后台回收线程进行空闲空间回收，负责主机上Undo模块的空间回收，备机通过回放xLog进行回收。回收线程遍历使用中的undo zone，对该zone中的txn page扫描，依据xid从小到大的顺序进行遍历。回收已提交或者已回滚完成的事务，且该事务的提交时间应早于$(current_time-undo_retention_time)。对于遍历过程中需要回滚的事务，后台回收线程会为该事务添加异步回滚任务。 当数据库中存在运行时间长、修改数据量大的事务，或者开启闪回时间较长的时候，可能出现undo空间持续膨胀的情况。当undo占用空间接近undo_space_limit_size时，就会触发强制回收。只要事务已提交或者已回滚完成，即使事务提交时间晚于$(current_time-undo_retention_time)，在这种情况下也可能被回收掉。 父主题： Undo

串行解码 force-binary： 是否以二进制格式输出解码结果，针对不同场景呈现不同行为。 针对系统函数pg_logical_slot_get_binary_changes和pg_logical_slot_peek_binary_changes： 取值范围：boolean型，默认值为false。此值无实际意义，均以二进制格式输出解码结果。 针对系统函数pg_logical_slot_get_changes、pg_logical_slot_peek_changes和pg_logical_get_area_changes： 取值范围：仅取false值的boolean型。以文本格式输出解码结果。 针对流式解码： 取值范围：boolean型，默认值为false。此值无实际意义，均以文本格式输出解码结果。

通用选项（串行解码和并行解码均可配置，但可能无效，请参考相关选项详细说明） include-xids： 解码出的data列是否包含xid信息。 取值范围：boolean型，默认值为true。 false：设为false时，解码出的data列不包含xid信息。 true：设为true时，解码出的data列包含xid信息。 skip-empty-xacts： 解码时是否忽略空事务信息。 取值范围：boolean型，默认值为false。 false：设为false时，解码时不忽略空事务信息。 true：设为true时，解码时会忽略空事务信息。 include-timestamp： 解码信息是否包含commit时间戳。 取值范围：boolean型，针对并行解码场景默认值为false，针对SQL函数解码和串行解码场景默认值为true。 false：设为false时，解码信息不包含commit时间戳。 true：设为true时，解码信息包含commit时间戳。 only-local： 是否仅解码本地日志。 取值范围：boolean型，默认值为true。 false：设为false时，解码非本地日志和本地日志。 true：设为true时，仅解码本地日志。 white-table-list： 白名单参数，包含需要进行解码的schema和表名。 取值范围：包含白名单中表名的字符串，不同的表以','为分隔符进行隔离；使用'*'来模糊匹配所有情况；schema名和表名间以'.'分割，不允许存在任意空白符。例如： select * from pg_logical_slot_peek_changes('slot1', NULL, 4096, 'white-table-list', 'public.t1,public.t2,*.t3,my_schema.*'); max-txn-in-memory： 内存管控参数，单位为MB，单个事务占用内存大于该值即进行落盘。 串行解码-取值范围：0~100的整型，默认值为0，即不开启此种管控。 并行解码-取值范围：0~max_process_memory总量的25%，默认值为max_process_memory/4/1024，其中1024为kB到MB的单位转换，0表示不开启此条内存管控项。 max-reorderbuffer-in-memory 内存管控参数，单位为GB，拼接-发送线程中正在拼接的事务总内存（包含缓存）大于该值则对当前解码事务进行落盘。 串行解码-取值范围：0~100的整型，默认值为0，即不开启此种管控。 并行解码-取值范围：0~max_process_memory总量的50%，默认值为max_process_memory/2/1048576，其中1048576为kB到GB的单位转换，0表示不开启此条内存管控项。 include-user： 事务的BEGIN逻辑日志是否输出事务的用户名。事务的用户名特指授权用户——执行事务对应会话的登录用户，它在事务的整个执行过程中不会发生变化。 取值范围：boolean型，默认值为false。 false：设为false时，事务的BEGIN逻辑日志不输出事务的用户名。 true：设为true时，事务的BEGIN逻辑日志输出事务的用户名。 exclude-userids： 黑名单用户的OID参数。 取值范围：字符串类型，指定黑名单用户的OID，多个OID通过','分隔，不校验用户OID是否存在。 exclude-users： 黑名单用户的名称列表。 取值范围：字符串类型，指定黑名单用户名，通过','分隔，不校验用户名是否存在。 dynamic-resolution： 是否动态解析黑名单用户名。 取值范围：boolean型，默认值为true。 false：设为false时，当解码观测到黑名单exclude-users中用户不存在时将会报错并退出逻辑解码。 true：设为true时，当解码观测到黑名单exclude-users中用户不存在时继续解码。 standby-connection： 仅流式解码设置，是否仅限制备机解码。 取值范围：boolean型，默认值为false。 true：设为true时，仅允许连接备机解码，连接主机解码时会报错退出。 false：设为false时，不做限制，允许连接主机或备机解码。 如果主机资源使用率较大，且业务对增量数据同步的实时性不敏感，建议进行备机解码；如果业务对增量数据同步的实时性要求高，并且主机业务压力较小，建议使用主机解码。 sender-timeout： 仅流式解码设置，内核与客户端的心跳超时阈值。如果该时间段内没有收到客户端任何消息，逻辑解码将主动停止，并断开和客户端的连接。单位为毫秒（ms）。 取值范围：0~2147483647的int型，默认值取决于GUC参数logical_sender_timeout的配置值。 change-log-max-len: 逻辑日志缓存长度上限参数，单位为字节，仅并行解码有效，串行解码及SQL函数解码无效。如果单条解码结果长度超过上限，则会销毁重新分配大小为1024字节的内存并缓存。过长会增加内存占用，过短会频繁触发内存申请和释放的操作，不建议设置成小于1024的值。 取值范围：1~65535，默认值为4096。 max-decode-to-sender-cache-num: 并行解码日志的缓存条数阈值，仅并行解码有效，串行解码及SQL函数解码无效。缓存中的日志条数未超过这个阈值时，使用完毕的解码日志将置入缓存，否则直接释放。 取值范围：1~65535，默认值为4096。 enable-heartbeat： 仅流式解码设置，代表是否输出心跳日志。 取值范围：boolean型，默认值为false。 true：设为true时，输出心跳日志。 false：设为false时，不输出心跳日志。 若开启心跳日志选项，此处说明并行解码场景心跳日志如何解析：二进制格式首先是字符'h'表示消息是心跳日志，之后是心跳日志内容，分别是8字节uint64代表LSN，表示发送心跳逻辑日志时读取的WAL日志结束位置；8字节uint64代表LSN，表示发送心跳逻辑日志时刻已经落盘的WAL日志的位置；8字节int64代表时间戳（从1970年1月1日开始），表示最新解码到的事务日志或检查点日志的产生时间戳。关于消息结束符：如果是二进制格式则为字符'F'，如果格式为text或者json且为批量发送则结束符为0，否则没有结束符。具体解析见下图： parallel-decode-num： 仅流式解码设置有效，并行解码的Decoder线程数量；系统函数调用场景下此选项无效，仅校验取值范围。 取值范围：1~20的int型，取1表示按照原有的串行逻辑进行解码，取其余值即为开启并行解码，默认值为1。 当parallel-decode-num不配置（即为默认值1）或显式配置为1时，下述“并行解码”中的选项不可配置。 output-order： 仅流式解码设置有效，代表是否使用CSN顺序输出解码结果；系统函数调用场景下此选项无效，仅校验取值范围。 取值范围：0或1的int型，默认值为0。 0：设为0时，解码结果按照事务的COMMIT LSN排序，当且仅当解码复制槽的confirmed_csn列值为0（即不显示）时可使用该方式，否则报错。 1：设为1时，解码结果按照事务的CSN排序，当且仅当解码复制槽的confirmed_csn列值为非零时可使用该方式，否则报错。 auto-advance： 仅流式解码设置有效，代表是否允许自主推进逻辑复制槽。 取值范围：boolean型，默认值为false。 true：设为true时，在已发送日志都被确认推进且没有待发送事务时，推进逻辑复制槽到当前解码位置。 false：设为false时，完全交由复制业务调用日志确认接口推进逻辑复制槽。 enable-ddl-decoding： 逻辑解码控制参数，用于控制DDL的反解析流程以及输出形式。 取值范围：boolean型，默认值为false。 true：值为true时，开启DDL语句的逻辑解码。 false：值为false时，不开启DDL语句的逻辑解码。 enable-ddl-json-format： 逻辑解码控制参数，用于控制DDL的反解析流程以及输出形式。 取值范围：boolean型，默认值为false。 true：值为true时，传送JSON格式的DDL反解析结果。 false：设为false时，传送TEXT格式的DDL反解析结果。 skip-generated-columns： 逻辑解码控制参数，用于跳过生成列的输出。对UPDATE和DELETE的旧元组无效，相应元组始终会输出生成列。 取值范围：boolean型，默认值为false。 true：值为true时，不输出生成列的解码结果。 false：设为false时，输出生成列的解码结果。

并行解码 以下配置选项仅限流式解码设置。 decode-style： 指定解码格式。 取值范围：char型的字符'j'、't'或'b'，分别代表json格式、text格式及二进制格式。默认值为'b'即二进制格式解码。 对于json格式和text格式解码，开启批量发送选项时的解码结果中，每条解码语句的前4字节组成的uint32代表该条语句总字节数（不包含该uint32类型占用的4字节，0代表本批次解码结束），8字节uint64代表相应lsn（begin对应first_lsn，commit对应end_lsn，其他场景对应该条语句的lsn）。 二进制格式编码规则如下所示： 前4字节代表接下来到语句级别分隔符字母P（不含）或者该批次结束符F（不含）的解码结果的总字节数，该值如果为0代表本批次解码结束。 接下来8字节uint64代表相应lsn（begin对应first_lsn，commit对应end_lsn，其他场景对应该条语句的lsn）。 接下来1字节的字母有5种B/C/I/U/D，分别代表begin/commit/insert/update/delete。 第3步字母为B时： 接下来的8字节uint64代表CSN。 接下来的8字节uint64代表first_lsn。 【该部分为可选项】接下来的1字节字母如果为T，则代表后面4字节uint32表示该事务commit时间戳长度，再后面等同于该长度的字符为时间戳字符串。 【该部分为可选项】接下来的1字节字母如果为N，则代表后面4字节uint32表示该事务用户名的长度，再后面等同于该长度的字符为事务的用户名字。 因为之后仍可能有解码语句，接下来会有1字节字母P或F作为语句间的分隔符，P代表本批次仍有解码的语句，F代表本批次解码完成。 第3步字母为C时： 【该部分为可选项】接下来1字节字母如果为X，则代表后面的8字节uint64表示xid。 【该部分为可选项】接下来的1字节字母如果为T，则代表后面4字节uint32表示时间戳长度，再后面等同于该长度的字符为时间戳字符串。 因为批量发送日志时，一个COMMIT日志解码之后可能仍有其他事务的解码结果，接下来的1字节字母如果为P则表示该批次仍需解码，如果为F则表示该批次解码结束。 第3步字母为I/U/D时： 接下来的2字节uint16代表schema名的长度。 按照上述长度读取schema名。 接下来的2字节uint16代表table名的长度。 按照上述长度读取table名。 【该部分为可选项】接下来1字节字母如果为N代表为新元组，如果为O代表为旧元组，这里先发送新元组。 接下来的2字节uint16代表该元组需要解码的列数，记为attrnum。 以下流程重复attrnum次。 接下来2字节uint16代表列名的长度。 按照上述长度读取列名。 接下来4字节uint32代表当前列类型的OID。 接下来4字节uint32代表当前列值（以字符串格式存储）的长度，如果为0xFFFFFFFF则表示NULL，如果为0则表示长度为0的字符串。 按照上述长度读取列值。 因为之后仍可能有解码语句，接下来的1字节字母如果为P则表示该批次仍需解码，如果为F则表示该批次解码结束。 sending-batch： 指定是否批量发送。 取值范围：0或1的int型，默认值为0。 0：设为0时，表示逐条发送解码结果。 1：设为1时，表示解码结果累积到达1MB则批量发送解码结果。 开启批量发送的场景中，当解码格式为'j'或't'时，在原来的每条解码语句之前会附加一个uint32类型，表示本条解码结果长度（长度不包含当前的uint32类型），以及一个uint64类型，表示当前解码结果对应的lsn。 在CSN序解码（即output-order设置为1）场景下，批量发送仅限于单个事务内（即如果一个事务有多条较小的语句会采用批量发送），即不会使用批量发送功能在同一批次里发送多个事务，且BEGIN和COMMIT语句不会批量发送。 parallel-queue-size： 指定并行逻辑解码线程间进行交互的队列长度。 取值范围：2~1024的int型，且必须为2的整数幂，默认值为128。 队列长度和解码过程的内存使用量正相关。 logical-reader-bind-cpu: reader线程绑定cpu核号的参数。 取值范围：-1~65535，不使用该参数则为不绑核。 默认-1，为不绑核。-1不可手动设置，核号应确保在机器总逻辑核数以内，不然会返回报错。多个线程绑定同一个核会导致该核负担加重，从而导致性能下降。 logical-decoder-bind-cpu-index： 逻辑解码线程绑定cpu核号的参数。 取值范围：-1~65535，不使用该参数则为不绑核。 默认-1，不绑核。-1不可手动设置，核号应确保在机器总逻辑核数以内且小于[cpu核数 - 并行逻辑解码数]，不然会返回报错。 从给定的核号参数开始，新拉起的线程会依次递增加一。 多个线程绑定同一个核会导致该核负担加重，从而导致性能下降。 GaussDB在进行逻辑解码和日志回放时，会占用大量的CPU资源，相关线程如Walwriter、WalSender、WALreceiver、pageredo就处于性能瓶颈，如果能将这些线程绑定在固定的CPU上运行，可以减少因操作系统调度线程频繁切换CPU，导致缓存未命中带来的性能开销，从而提高流程处理速度，如用户场景有性能需求，可根据以下的绑核样例进行配置优化。 参数样例： walwriter_cpu_bind=1 walwriteraux_bind_cpu=2 wal_receiver_bind_cpu=4 wal_rec_writer_bind_cpu=5 wal_sender_bind_cpu_attr='cpuorderbind:7-14' redo_bind_cpu_attr='cpuorderbind:16-19' logical-reader-bind-cpu=20 logical-decoder-bind-cpu-index=21 样例中1.2.3.4.5.6通过GUC工具设置，使用指令如 gs_guc set -Z datanode -N all -I all -c “walwriter_cpu_bind=1”。 样例中7.8通过JDBC客户端发起解码请求时添加。 样例中如walwriter_cpu_bind=1是限定该线程在1号CPU上运行。 cpuorderbind：7-14意为拉起的每个线程依次绑定7号到14号CPU，如果范围内的CPU用完，则新拉起的线程不参与绑核。 logical-decoder-bind-cpu-index意为拉起的线程从21号CPU依次开始绑定，后续拉起的线程分别绑定21、22、23，依次类推。 绑核的原则是一个线程占用一个CPU，样例中的GUC参数说明可参考管理员指南。 不恰当的绑核，例如将多个线程绑定在一个CPU上很有可能带来性能劣化。 可以通过lscpu指令查看“CPU(s):”得知自己环境的CPU逻辑核心数。 CPU逻辑核心数低于36则不建议使用此套绑核策略，此时建议使用默认配置（不进行参数设置）。

RCR Uheap多版本管理 Ustore对其使用的heap做了如下重要的增强，简称Uheap。 Ustore RCR(Row Consistency Read)的多版本管理是基于数据行的行级多版本管理，不过Ustore将XID记录在了页面的TD(Transaction Directory)区域，区别于常见的将XID存储在数据行上，节省了页面空间。事务修改记录时，会将历史数据记录到Undo Row中，在Tuple中的td_id指向的TD槽上记录产生的Undo Row地址(zone_id, block no, page offset)，并将新的数据覆盖写入页面。访问元组时，沿着版本链还原该元组，直到找到自己对应的版本。 父主题： RCR Uheap

创建普通分区表（创建一级分区表） 由于SQL语言功能强大和灵活多样性，SQL语法树通常比复杂，分区表同样如此，分区表的创建可以理解成在原有非分区表的基础上新增表分区属性，因此分区表的语法接口可以看成是对原有非分区表CREATE TABLE语句进行扩展PARTITION BY语句部分，同时指定分区相关的三个核元素： 分区类型（partType）：描述分区表的分区策略，分别有RANGE/INTERVAL/LIST/HASH。 分区键（partKey）：描述分区表的分区列，目前RANGE/LIST分区支持多列（不超过16列）分区键，INTERVAL/HASH分区只支持单列分区。 分区表达式（partExpr）：描述分区表的具体分区表方式，即键值与分区的对应映射关系。 这三部分重要元素在建表语句的Partition By Clause子句中体现，PARTITION BY partType (partKey) ( partExpr[,partExpr]…)。示例如下： CREATE TABLE [ IF NOT EXISTS ] partition_table_name ( [ /* 该部分继承于普通表的Create Table */ { column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ] | table_constraint | LIKE source_table [ like_option [...] ] }[, ... ] ] ) [ WITH ( {storage_parameter = value} [, ... ] ) ] [ COMPRESS | NOCOMPRESS ] [ TABLESPACE tablespace_name ] /* 范围分区场景，若申明INTERVAL子句则为间隔分区场景 */ PARTITION BY RANGE (partKey) [ INTERVAL ('interval_expr') [ STORE IN (tablespace_name [, ... ] ) ] ] ( partition_start_end_item [, ... ] partition_less_then_item [, ... ] ) /* 列表分区场景，若申明AUTOMATIC则支持list自动扩展 */ PARTITION BY LIST (partKey) [ AUTOMATIC ] ( PARTITION partition_name VALUES (list_values_clause) [ TABLESPACE tablespace_name [, ... ] ] ... ) /* 哈希分区场景 */ PARTITION BY HASH (partKey) ( PARTITION partition_name [ TABLESPACE tablespace_name [, ... ] ] ... ) /* 开启/关闭分区表行迁移 */ [ { ENABLE | DISABLE } ROW MOVEMENT ]; 规格约束： RANGE/LIST分区最大支持16个分区键，INTERVAL/HASH分区均只支持1个分区键，二级分区只支持1个分区键。 INTERVAL分区仅支持数值类型和日期/时间类型，INTERVAL分区不支持在二级分区表中创建。 INTERVAL分区表定义不能有MAXVALUE分区，LIST自动扩展分区表不能定义有DEFAULT分区。 除哈希分区外，分区键不能插入空值，否则DML语句会进行报错处理。唯一例外：RANGE分区表定义有MAXVALUE分区/LIST分区表定义有DEFAULT分区。 分区数最大值为1048575个，可以满足大部分业务场景的诉求。但分区数增加会导致系统中文件数增加，影响系统的性能，一般对于单个表而言不建议分区数超过200。

创建二级分区表 二级分区表，可以看成是对一级分区表的扩展，在二级分区表中第一层分区是一张逻辑表并不实际存储数据，数据实际是存储在二级分区节点上的。从实现上而言，二级分区表的分区方案是由两个一级分区的嵌套而来，一级分区的分区方案详见章节CREATE TABLE PARTITION。常见的二级分区表组合方案有：Range-Range分区、Range-List分区、Range-Hash分区、List-Range分区、List-List分区、List-Hash分区、Hash-Range分区、Hash-List分区、Hash-Hash分区等。目前二级分区仅支持行存表，二级分区创建的示例如下： CREATE TABLE [ IF NOT EXISTS ] subpartition_table_name ( [ /* 该部份继承于普通表的Create Table */ { column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ] | table_constraint | LIKE source_table [ like_option [...] ] } [, ... ] ] ) [ WITH ( {storage_parameter = value} [, ... ] ) ] [ COMPRESS | NOCOMPRESS ] [ TABLESPACE tablespace_name ] /* 二级分区定义的部分，只有list分区策略支持申明AUTOMATIC */ PARTITION BY {RANGE | LIST | HASH} (partKey) [ AUTOMATIC ] SUBPARTITOIN BY {RANGE | LIST | HASH} (partKey) [ AUTOMATIC ] ( PARTITION partition_name partExpr… /* 第一层分区 */ ( SUBPARTITION partition_name partExpr … /* 第二层分区 */ SUBPARTITION partition_name partExpr … /* 第二层分区 */ ), PARTITION partition_name partExpr… /* 第一层分区 */ ( SUBPARTITION partition_name partExpr … /* 第二层分区 */ SUBPARTITION partition_name partExpr … /* 第二层分区 */ ), … ) [ { ENABLE | DISABLE } ROW MOVEMENT ]; 规格约束： 二级分区表支持LIST/HASH/RANGE分区的任意两两组合。 二级分区表支持任一层LIST申明自动扩展。 二级分区表的第二层分区采用LIST自动扩展时，建表语句中第二层分区定义不能为空。 二级分区表场景中仅支持单分区键。 二级分区表中不支持INTERVAL类型分区的组合。 二级分区表场景中，分区总数上限为1048575。

问题分析 在开启并行回放或串行回放的情况下（查询GUC参数recovery_parse_workers和recovery_max_workers均是1为串行回放；recovery_parse_workers是1，recovery_max_workers大于1为并行回放），备机的查询线程在做索引扫描时，会先对索引页面加读锁，每当扫到一个元组时会去判可见性，如果该元组对应的事务处于committing状态，需要等待该事务提交后再判断。而备机上的事务提交是依赖日志回放线程推进的，这个过程中会对索引页面进行修改，因此需要加锁。查询线程在等待过程中会释放索引页面的锁，否则会出现查询线程等待回放线程进行事务提交，而回放线程在等待查询线程释放锁。 该报错仅出现在查询与回放都需要访问同一个索引页面的场景下，查询线程在释放锁并等待事务结束过程中，访问的页面出现被修改的情况。具体流程图如下图1所示： 备机查询在扫到committing状态的元组时，需要等待事务提交是因为事务提交的顺序与产生日志的顺序可能是乱序的，例如主机上tx_1的事务比tx_2先提交，而备机上tx_1的commit日志在tx_2的commit日志之后回放，按照事务提交顺序来看tx_1对tx_2应当是可见的，所以需要等待事务提交。 备机查询在扫描索引页面时，发现页面元组数量（包含死元组）发生变化后不可重试，是因为在扫描时可能为正向或反向扫描，而举例来说页面发生分裂后一部分元组移动到右页面，在反向扫描的情况下即使重试只能向左扫描读取，无法再保证结果的正确性，并且由于无法分辨发生分裂或者插入，所以不可重试。 图1 问题分析

大容量数据库背景介绍 随着处理数据量的日益增长和使用场景的多样化，数据库越来越多地面对容量大、数据多样化的场景。在过去数据库业界发展的20多年时间里，数据量从最初的MB、GB级数据量逐渐发展到现在的TB级数据量，在如此数据大规模、数据多样化的客观背景下，数据库管理系统（DBMS）在数据查询、数据管理方面提出了更高的要求，客观上要求数据库能够支持多种优化查找策略和管理运维方式。 在计算机科学经典的算法中，人们通常使用分治法（Divide and Conquer）解决场景和规模较大的问题。其基本思想就是把一个复杂的问题分成两个或更多的相同或相似的子问题，再把子问题分成更小的子问题直到最后子问题可以简单的直接求解，原问题的解可看成子问题的解的合并。对于大容量数据场景，数据库提供对数据进行“分治处理”的方式即分区，将逻辑数据库或其组成元素划分为不同的独立部分，每一个分区维护逻辑上存在相类似属性的数据，这样就把庞大的数据整体进行了切分，有利于数据的管理、查找和维护。 父主题： 大容量数据库

合并分区 用户可以使用合并分区的命令来将多个分区合并为一个分区。合并分区只能通过指定分区名来进行，不支持指定分区值的写法。 合并分区不能作用于哈希分区上。 执行合并分区命令会使得Global索引失效，可以通过UPDATE GLOBAL INDEX子句来同步更新Global索引，或者用户自行重建Global索引。 合并前的分区如果包含分类索引则不支持合并。 合并后的新分区，对于范围/间隔分区，可以与最后一个源分区名字相同，比如将p1,p2合并为p2；对于列表分区，可以与任一源分区名字相同，比如将p1,p2合并为p1。 如果新分区与源分区名字相同，数据库会将新分区视为对源分区的继承，这会影响合并期间对源分区查询的行为，具体请参见DQL/DML-DDL并发。 对一级分区表合并分区 对二级分区表合并二级分区 父主题： 分区表运维管理

列表分区 列表分区（List Partition）能够通过在每个分区的描述中为分区键指定离散值列表来显式控制行如何映射到分区。列表分区的优势在于可以以枚举分区值方式对数据进行分区，可以对无序和不相关的数据集进行分组和组织。对于未定义在列表中的分区键值，可以使用默认分区（DEFAULT）来进行数据的保存，这样所有未映射到任何其他分区的行都不会生成错误。示例如下： gaussdb=# CREATE TABLE bmsql_order_line ( ol_w_id INTEGER NOT NULL, ol_d_id INTEGER NOT NULL, ol_o_id INTEGER NOT NULL, ol_number INTEGER NOT NULL, ol_i_id INTEGER NOT NULL, ol_delivery_d TIMESTAMP, ol_amount DECIMAL(6,2), ol_supply_w_id INTEGER, ol_quantity INTEGER, ol_dist_info CHAR(24) ) PARTITION BY LIST(ol_d_id) ( PARTITION p0 VALUES (1,4,7), PARTITION p1 VALUES (2,5,8), PARTITION p2 VALUES (3,6,9), PARTITION p3 VALUES (DEFAULT) ); gaussdb=# DROP TABLE bmsql_order_line; 上述例子和之前给出的哈希分区的例子类似，同样通过ol_d_id列进行分区，但是在List分区中直接通过对ol_d_id的可能取值范围进行限定，不在列表中的数据会进入p3分区（DEFAULT）。相比哈希分区，List列表分区对分区键的可控性更好，往往能够准确的将目标数据保存在预想的分区中，但是如果列表值较多在分区定义时变得麻烦，该情况下推荐使用Hash分区。List、Hash分区往往都是处理无序、不相关的数据集进行分组和组织。 列表分区的分区键最多支持16列。如果分区键定义为1列，子分区定义时List列表中的枚举值不允许为NULL值；如果分区键定义为多列，子分区定义时List列表中的枚举值允许有NULL值。 父主题： 分区策略

分区（分区子表、子分区） 分区表中实际保存数据的表，对应的entry通常保存在pg_partition中，各个子分区的parentid作为外键关联其分区母表在pg_class表中的OID列。 示例：t1_hash为一个一级分区表： gaussdb=# CREATE TABLE t1_hash (c1 INT, c2 INT, c3 INT) PARTITION BY HASH(c1) ( PARTITION p0, PARTITION p1, PARTITION p2, PARTITION p3, PARTITION p4, PARTITION p5, PARTITION p6, PARTITION p7, PARTITION p8, PARTITION p9 ); --查询t1_hash分区类型 gaussdb=# SELECT oid, relname, parttype FROM pg_class WHERE relname = 't1_hash'; oid | relname | parttype -------+---------+---------- 16685 | t1_hash | p (1 row) --查询t1_hash的分区信息 gaussdb=# SELECT oid, relname, parttype, parentid FROM pg_partition WHERE parentid = 16685; oid | relname | parttype | parentid -------+---------+----------+---------- 16688 | t1_hash | r | 16685 16689 | p0 | p | 16685 16690 | p1 | p | 16685 16691 | p2 | p | 16685 16692 | p3 | p | 16685 16693 | p4 | p | 16685 16694 | p5 | p | 16685 16695 | p6 | p | 16685 16696 | p7 | p | 16685 16697 | p8 | p | 16685 16698 | p9 | p | 16685 (11 rows) gaussdb=# DROP TABLE t1_hash; 父主题： 基本概念

维护窗口参数配置 RETENTION_TIME：评估与压缩记录的保留时长，单位天，默认值30。用户可根据自己存储容量自行调节。 EXECUTION_INTERVAL：评估任务的执行频率，单位分钟，默认值15。用户可根据自己维护窗口期间业务与资源情况调节。该参数与ABS_JOBLIMIT相互影响。单日单线程最大可产生的I/O为WIND_DURATION/EXECUTION_INTERVAL*JOB_SIZELIMIT。 JOB_SIZELIMIT：控制单个压缩Job可以处理的最大字节数，单位兆，默认值1024。压缩带宽约为100MB/秒，每个压缩Job限制IO为1GB时，最多10秒完成。用户可根据自己业务闲时情况以及需要压缩的数据量自行调节。 ABS_JOBLIMIT：控制一次评估最多生成多少个压缩Job。用户可根据自己设置策略的分区及表数量自己调节。建议最大不超过10，可以使用“select count(*) from gs_adm_ilmobjects where enabled = true”命令查询。 POLICY_TIME：控制判定冷行的条件单位是天还是秒，秒仅用来做测试用。取值为：ILM_POLICY_IN_SECONDS或ILM_POLICY_IN_DAYS（默认值）。 WIND_DURATION：维护窗口持续时长，单位分钟，默认240分钟（4小时）。维护窗口默认从22：00（北京时间）开始持续240分钟，用户可根据自己业务闲时情况自行调节。 BLOCK_LIMITS：控制实例级的行存压缩速率上限，默认是40，取值范围是0到10000(0表示不限制)，单位是block/ms，表示每毫秒最多压缩多少个block。速率上限计算方法：BLOCK_LIMITS*1000*BLOCKSIZE，以默认值40为例，其速率上限为:40*1000*8KB=320000KB/s。 示例分析： EXECUTION_INTERVAL：15 JOB_SIZELIMIT：10240 WIND_DURATION：240 BLOCK_LIMITS：0 此配置下单表分区或子分区在一个维护窗口期间可完成240/15*10240MB=160GB数据的评估压缩。压缩带宽为100MB/秒，实际压缩仅耗时160GB/(100MB/秒)=27分钟。其他时间对业务无影响。用户可根据自己业务闲时可支配给压缩的时长来调节参数。 父主题： 数据生命周期管理-OLTP表压缩