CREATE TABLE

Updated on 2025-01-07 GMT+08:00

View PDF

Function

Create an HStore table in the current database. The table will be owned by the user who created it.

In a hybrid data warehouse, you can use DDL statements to create HStore tables. To create an HStore table, set enable_hstore to true and set orientation to column.

NOTE:

To use hybrid data warehouse capabilities, choose the storage-compute coupled architecture when you create a GaussDB(DWS) cluster on the console and ensure the vCPU to memory ratio is 1:4 when setting up cloud disk flavors. For more information, see Data Warehouse Flavors.
When setting up a GaussDB(DWS) cluster, make sure to have a vCPU to memory ratio of 1:8 for standard data warehouses and a ratio of 1:4 for hybrid data warehouses. You can distinguish a standard data warehouse from a real-time data warehouse by comparing their vCPU to memory ratios.

Precautions

When creating an HStore table, ensure that the database GUC parameter settings meet the following requirements:
- autovacuum is set to on.
- The value of autovacuum_max_workers_hstore is greater than 0.
- The value of autovacuum_max_workers is greater than that of autovacuum_max_workers_hstore.
To create an HStore table, you must have the USAGE permission on schema cstore.
The table-level parameters enable_delta and enable_hstore cannot be enabled at the same time. The parameter enable_delta is used to enable delta for common column-store tables and conflicts with enable_hstore.
Each HStore table is bound to a delta table. The OID of the delta table is recorded in the reldeltaidx field in pg_class. (The reldelta field is used by the delta table of the column-store table).

Syntax

    
     
       
       CREATE TABLE [ IF NOT EXISTS ] table_name
({ column_name data_type 
    | LIKE source_table [like_option [...] ] }
}
    [, ... ])
[ WITH ( {storage_parameter = value}  [, ... ] ) ]
[ TABLESPACE tablespace_name ]
[ DISTRIBUTE BY  HASH ( column_name [,...])]
[ TO { GROUP groupname | NODE ( nodename [, ... ] ) } ]
[ PARTITION BY { 
        {RANGE (partition_key) ( partition_less_than_item [, ... ] )} 
 } [ { ENABLE | DISABLE } ROW MOVEMENT ] ]; 
The options for LIKE are as follows:
{ INCLUDING | EXCLUDING } { DEFAULTS | CONSTRAINTS | INDEXES | STORAGE | COMMENTS | PARTITION | RELOPTIONS | DISTRIBUTION | ALL }

      

    
   

Differences Between Delta Tables

**Table 1** Differences between the delta tables of HStore and column-store tables
Type	Column-Store Delta Table	HStore Delta Table	HStore Opt Delta Table
Table structure	Same as that defined for the column-store primary table.	Different from that defined for the primary table.	Different from the definitions of the primary table and but same as the definitions of the HStore table.
Functionality	Used to temporarily store a small batch of inserted data. After the data size reaches the threshold, the data will be merged to the primary table. In this way, data will not be directly inserted to the primary table or generate a large number of small CUs.	Persistently stores UPDATE, DELETE, and INSERT information. It is used to restore the memory structure that manages concurrent updates, such as the memory update chain, in the case of a fault.	Persistently stores UPDATE, DELETE, and INSERT information. It is used to restore the memory structure that manages concurrent updates, such as the memory update chain, in the case of a fault. It is further optimized compared with HStore.
Weakness	If data is not merged in a timely manner, the delta table will grow large and affect query performance. In addition, the table cannot solve lock conflicts during concurrent updates.	The merge operation depends on the background AUTOVACUUM.	The merge operation depends on the background AUTOVACUUM.
Specification differences	Concurrent requests in the same CU are not supported. It is applicable to the scenario where there are not many concurrent updates.	Insertion and update restrictions: MERGE INTO does not support concurrent updates of the same row or repeated updates of the same key. Concurrent UPDATE or DELETE operations on the same row are not supported. Otherwise, an error is reported. Index and query restrictions: Indexes do not support array condition filtering, IN expression filtering, partial indexes, or expression indexes. Indexes cannot be invalidated. Table structure and operation restrictions: Ensure that the tables to be exchanged are HStore tables during partition exchange or relfilenode operations. The distribution column cannot be modified using the UPDATE command. You are not advised to modify the partition column using the UPDATE command. (No error is reported, but the performance is poor.)	Insertion and update restrictions: MERGE INTO does not support concurrent updates of the same row or repeated updates of the same key. Concurrent updates or deletions of the same row is not supported. hstore_opt does not support cross-partition upserts. Index and query restrictions: Bitmap indexes are supported. Global dictionaries are supported. bitmap_columns must be specified during table creation and cannot be modified after being set. The opt version does not support transparent parameter transmission during SMP streaming. In multi-table join queries that require partition pruning, avoid using replicated tables or setting query_dop. Table structure and operation restrictions: Distribution columns and partition columns cannot be modified using UPDATE. The enable_hstore_opt attribute must be set when the table is created and cannot be changed after being set.
Data import suggestions	For optimal data import, query performance, and space utilization, it is recommended to choose the HStore Opt table. In scenarios involving micro-batch copying with high performance demands and no data updates, you can choose the HStore table. Similarities between HStore and HStore Opt tables: The performance of importing data using UPDATE is poor. You are advised to use UPSERT to import data. When using DELETE to import data, use index scanning. The JDBC batch method is recommended. Use MERGE INTO to import data records to the database when the data volume exceeds 1 million per DN and there is no concurrent data. Do not modify or add data in cold partitions. Suggestions on HStore table data import using UPSERT: Select a method. Step 1: Select Method 2 for partial column upsert. For full column upsert (update all columns to new values without expressions when a conflict occurs), go to step 2. Step 2: Check whether data is concurrently updated to the same key when being imported to the database. If no conflict occurs, select Method 1. If a conflict occurs, go to step 3. Step 3: If duplicate data exists in the database, select Method 2. Otherwise, go to step 4. Step 4: If copying of temporary tables is used for import, select Method 3. Otherwise, select Method 2. The methods are as follows: Method 1: Enable enable_hstore_nonconflict_upsert_optimization and disable enable_hstore_partial_upsert_optimization. Method 2: Disable enable_hstore_nonconflict_upsert_optimization and enable enable_hstore_partial_upsert_optimization. Method 3: Disable enable_hstore_nonconflict_upsert_optimization and enable_hstore_partial_upsert_optimization. Note: If the number of accumulated batches is less than 2,000, import data in batches into the database. For accumulated batches exceeding 2,000, import data into the database by copying temporary tables. Suggestions on HStore Opt table data import using UPSERT: If there is no concurrency conflict, enable the enable_hstore_nonconflict_upsert_optimization parameter. In other scenarios, disable the parameter. The optimal path is automatically selected.
Point query suggestions	Generally, the HStore Opt table is recommended for point queries. Similarities between HStore and HStore Opt tables: Create a level-2 partition on the column where the equal-value filter condition is most frequently used and distinct values are evenly distributed. Suggestions on using HStore tables for point queries: Accelerating indexes other than primary keys may have poor effect. You are advised not to enable index acceleration. If the data type is numeric or strings less than 16 bytes, Turbo acceleration is recommended. Suggestions on using HStore Opt tables: For equal-value filter columns not in level-2 partitions, if the columns involved in the filter criteria are basically fixed in the query, use the CB-tree index. If the columns change continuously, you are advised to use the GIN index. Do not select more than five index columns. For all string columns involving equivalent filtering, bitmap indexes can be specified during table creation. The number of columns is not limited, but cannot be modified later. Specify columns that can be filtered by time range as the partition columns. If the number of returned data records exceeds 100,000 per DN, index scanning may not significantly enhance performance. In this case, you are advised to use the GUC parameter enable_seqscan to test the performance then determine which optimization method to use.

Parameters

IF NOT EXISTS
If IF NOT EXISTS is specified, a table will be created if there is no table using the specified name. If there is already a table using the specified name, no error will be reported. A message will be displayed indicating that the table already exists, and the database will skip table creation.
table_name
Specifies the name of the table to be created.

The table name can contain a maximum of 63 characters, including letters, digits, underscores (_), dollar signs ($), and number signs (#). It must start with a letter or underscore (_).
column_name
Specifies the name of a column to be created in the new table.

The column name can contain a maximum of 63 characters, including letters, digits, underscores (_), dollar signs ($), and number signs (#). It must start with a letter or underscore (_).
data_type
Specifies the data type of the column.
LIKE source_table [ like_option ... ]
Specifies a table from which the new table automatically copies all column names and their data types.

The new table and the original table are decoupled after creation is complete. Changes to the original table will not be applied to the new table, and scans on the original table will not be performed on the data of the new table.

Columns copied by LIKE are not merged with the same name. If the same name is specified explicitly or in another LIKE clause, an error will be reported.

HStore tables can be inherited only from HStore tables.
WITH ( { storage_parameter = value } [, ... ] )
Specifies an optional storage parameter for a table.
- ORIENTATION
  Specifies the storage mode (time series, row-store, or column-store) of table data. This parameter cannot be modified once it is set. For HStore tables, use the column storage mode and set enable_hstore to on.
  
  Options:
  - TIMESERIES indicates that the data is stored in time series.
  - COLUMN indicates that the data is stored in columns.
  - ROW indicates that table data is stored in rows.
  Default value: ROW
- COMPRESSION
  Specifies the compression level of the table data. It determines the compression ratio and time. Generally, a higher compression level indicates a higher compression ratio and a longer compression time, and vice versa. The actual compression ratio depends on the distribution characteristics of loading table data.
  
  Options:
  - The valid values for HStore tables and column-store tables are YES/NO and LOW/MIDDLE/HIGH, and the default is LOW.
  - The valid values for row-store tables are YES and NO, and the default is NO.
- COMPRESSLEVEL
  Specifies table data compression rate and duration at the same compression level. This divides a compression level into sub-levels, providing you with more choices for compression ratio and duration. As the value becomes greater, the compression rate becomes higher and duration longer at the same compression level. The parameter is only valid for time series tables and column-store tables.
  
  Value range: 0 to 3
  
  Default value: 0
- MAX_BATCHROW
  Specifies the maximum number of rows in a storage unit during data loading. The parameter is only valid for time series tables and column-store tables.
  
  Value range: 10000 to 60000
  
  Default value: 60000
- PARTIAL_CLUSTER_ROWS
  Specifies the number of records to be partially clustered for storage during data loading. The parameter is only valid for time series tables and column-store tables.
  
  Value range: 600000 to 2147483647
- enable_delta
  Specifies whether to enable delta tables in column-store tables. This parameter cannot be enabled for HStore tables.
  
  Default value: off
- enable_hstore
  Specifies whether to create a table as an HStore table (based on column-store tables). The parameter is only valid for column-store tables. This parameter is supported by version 8.2.0.100 or later clusters.
  
  Default value: off
  
  NOTE:
  
  If this parameter is enabled, the following GUC parameters must be set to ensure that HStore tables are cleared.
  
  autovacuum=true, autovacuum_max_workers=6, autovacuum_max_workers_hstore=3.
- enable_disaster_cstore
  Specifies whether fine-grained DR will be enabled for column-store tables. This parameter only takes effect on column-store tables whose COLVERSION is 2.0 and cannot be set to on if enable_hstore is on. This parameter is supported by version 8.2.0.100 or later clusters.
  
  Default value: off
  
  CAUTION:
  
  Before enabling this function, set the GUC parameter enable_metadata_tracking to on. Otherwise, fine-grained DR may fail to be enabled.
- SUB_PARTITION_COUNT
  Specifies the number of level-2 partitions. This parameter specifies the number of level-2 partitions during data import. This parameter is configured during table creation and cannot be modified after table creation. You are not advised to set the default value, which may affect the import and query performance.
  
  Value range: 1 to 1024
  
  Default value: 32
- DELTAROW_THRESHOLD
  Specifies the maximum number of rows (SUB_PARTITION_COUNT x DELTAROW_THRESHOLD) to be imported to the delta table.
  
  Value range: 0 to 60000
  
  Default value: 60000
- COLVERSION
  Specifies the version of the storage format. HStore tables support only version 2.0, and enable_hstore_opt tables support versions 2.0 and 3.0.
  
  Options:
  
  1.0: Each column in a column-store table is stored in a separate file. The file name is relfilenode.C1.0, relfilenode.C2.0, relfilenode.C3.0, or similar.
  
  2.0: All columns of a column-store table are combined and stored in a file. The file is named relfilenode.C1.0.
  
  Default value: 2.0
- enable_binlog
  Specifies whether to enable the binlog function for the HStore table. This parameter is supported only by clusters of version 8.3.0.100 or later.
  
  Value range: on and off
  
  Default value: off
- enable_binlog_timestamp
  Determines whether to enable the binlog function with timestamps for HStore tables. This parameter and enable_binlog cannot be enabled at the same time. Only clusters of 9.1.0.200 and later versions support this parameter.
  
  Value range: on and off
  
  Default value: off
- DISTRIBUTE BY
  Specifies how the table is distributed or replicated between DNs.
  
  Options:
  
  HASH (column_name): Each row of the table will be placed into all the DNs based on the hash value of the specified column.
- TO { GROUP groupname | NODE ( nodename [, ... ] ) }
  TO GROUP specifies the Node Group in which the table is created. Currently, it cannot be used for HDFS tables. TO NODE is used for internal scale-out tools.
- PARTITION BY
  Specifies the initial partition of an HStore table.
- secondary_part_column
  Specifies the name of a level-2 partition column in a column-store table. Only one column can be specified as the level-2 partition column. This parameter applies only to HStore column-store tables. This parameter is supported only by clusters of version 8.3.0 and later. V3 tables do not support this parameter and will use hashbucket pruning.
  NOTE:
  - The column specified as a level-2 partition column cannot be deleted or modified.
  - The level-2 partition column can be specified only when a table is created. After a table is created, the level-2 partition column cannot be modified.
  - You are not advised to specify a distribution column as a level-2 partition column.
  - The level-2 partition column determines how the table is logically split into hash partitions on DNs, which enhances the query performance for that column.
- secondary_part_num
  Specifies the number of level-2 partitions in a column-store table. This parameter applies only to HStore column-store tables. This parameter is supported only by clusters of version 8.3.0 and later. V3 tables do not support this parameter and will use hashbucket pruning.
  
  Value range: 1 to 32
  
  Default value: 8
  NOTE:
  - This parameter can be specified only when secondary_part_column is specified.
  - The number of level-2 partitions can be specified only when a table is created and cannot be modified after the table is created.
  - You are not advised to change the default value, which may affect the import and query performance.

Example

Create a simple HStore table.

CREATE TABLE warehouse_t1
(
    W_WAREHOUSE_SK            INTEGER               NOT NULL,
    W_WAREHOUSE_ID            CHAR(16)              NOT NULL,
    W_WAREHOUSE_NAME          VARCHAR(20)                   ,
    W_WAREHOUSE_SQ_FT         INTEGER                       ,
    W_STREET_NUMBER           CHAR(10)                      ,
    W_STREET_NAME             VARCHAR(60)                   ,
    W_STREET_TYPE             CHAR(15)                      ,
    W_SUITE_NUMBER            CHAR(10)                      ,
    W_CITY                    VARCHAR(60)                   ,
    W_COUNTY                  VARCHAR(30)                   ,
    W_STATE                   CHAR(2)                       ,
    W_ZIP                     CHAR(10)                      ,
    W_COUNTRY                 VARCHAR(20)                   ,
    W_GMT_OFFSET              DECIMAL(5,2)
)WITH(ORIENTATION=COLUMN, ENABLE_HSTORE=ON);

CREATE TABLE warehouse_t2 (LIKE warehouse_t1 INCLUDING ALL);

Parent topic: Hybrid Data Warehouse Syntax

Previous topic: Hybrid Data Warehouse Syntax

Next topic: INSERT