diff --git a/docs/opengauss/umn/ALL_META.TXT.json b/docs/opengauss/umn/ALL_META.TXT.json index b2a64c6a7..d579796df 100644 --- a/docs/opengauss/umn/ALL_META.TXT.json +++ b/docs/opengauss/umn/ALL_META.TXT.json @@ -196,7 +196,7 @@ "node_id":"en-us_topic_0000002088677498.xml", "product_code":"opengauss", "code":"10", - "des":"Currently, GaussDB 8.103, 3.223, 3.222, 3.208, 3.103, 2.7, 2.3, 1.4, and 1.0 are supported.", + "des":"Currently, GaussDB V2.0-8.102, V2.0-3.223, V2.0-3.222, and V2.0-3.208 are supported.", "doc_type":"usermanual", "kw":"Instance Versions,DB Instance Description,User Guide", "search_title":"", @@ -3218,7 +3218,7 @@ "code":"154", "des":"The nesting depth of multi-table association must be less than 8.If the association nesting is too deep, slow SQL statements may be generated. You need to optimize the as", "doc_type":"usermanual", - "kw":"Associated Query,Database Programming Guidelines,User Guide", + "kw":"Join Query,Database Programming Guidelines,User Guide", "search_title":"", "metedata":[ { @@ -3229,7 +3229,7 @@ "IsBot":"Yes" } ], - "title":"Associated Query", + "title":"Join Query", "githuburl":"" }, { @@ -3510,7 +3510,7 @@ "node_id":"en-us_topic_0000002088677158.xml", "product_code":"opengauss", "code":"168", - "des":"When workloads on a DB instance are heavy, the playback speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, l", + "des":"When workloads on a DB instance are heavy, the replay speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, log", "doc_type":"usermanual", "kw":"What Do I Do If Replay Speed of Standby Nodes Cannot Catch Up with Write Speed of Primary Nodes?,FAQ", "search_title":"", diff --git a/docs/opengauss/umn/CLASS.TXT.json b/docs/opengauss/umn/CLASS.TXT.json index 9f13014ab..cb829c4c1 100644 --- a/docs/opengauss/umn/CLASS.TXT.json +++ b/docs/opengauss/umn/CLASS.TXT.json @@ -81,7 +81,7 @@ "code":"9" }, { - "desc":"Currently, GaussDB 8.103, 3.223, 3.222, 3.208, 3.103, 2.7, 2.3, 1.4, and 1.0 are supported.", + "desc":"Currently, GaussDB V2.0-8.102, V2.0-3.223, V2.0-3.222, and V2.0-3.208 are supported.", "product_code":"opengauss", "title":"Instance Versions", "uri":"opengauss_01_0008.html", @@ -1379,7 +1379,7 @@ { "desc":"The nesting depth of multi-table association must be less than 8.If the association nesting is too deep, slow SQL statements may be generated. You need to optimize the as", "product_code":"opengauss", - "title":"Associated Query", + "title":"Join Query", "uri":"opengauss_tips_0022.html", "doc_type":"usermanual", "p_code":"146", @@ -1503,7 +1503,7 @@ "code":"167" }, { - "desc":"When workloads on a DB instance are heavy, the playback speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, l", + "desc":"When workloads on a DB instance are heavy, the replay speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, log", "product_code":"opengauss", "title":"What Do I Do If Replay Speed of Standby Nodes Cannot Catch Up with Write Speed of Primary Nodes?", "uri":"opengauss_faq_0010.html", diff --git a/docs/opengauss/umn/opengauss_01_0003.html b/docs/opengauss/umn/opengauss_01_0003.html index 6eb067505..00d9a7884 100644 --- a/docs/opengauss/umn/opengauss_01_0003.html +++ b/docs/opengauss/umn/opengauss_01_0003.html @@ -3,7 +3,7 @@

Basic Concepts

Instances

The smallest management unit in GaussDB is the instance. A DB instance is an isolated database environment hosted in the cloud. You can create and manage GaussDB instances on the management console. For details about instance statuses, instance specifications, storage types, and versions, see DB Instance Description.

-

Instance Versions

Currently, GaussDB 8.103, 3.223, 3.222, 3.208, 3.103, 2.7, 2.3, 1.4, and 1.0 are supported.

+

Instance Versions

Currently, GaussDB V2.0-8.102, V2.0-3.223, V2.0-3.222, and V2.0-3.208 are supported.

Instance Types

GaussDB supports distributed instances. Distributed instances allow you to add nodes as needed to handle large volumes of concurrent requests. The primary/standby instances are suitable for scenarios with small and stable volumes of data, where data reliability and service availability are important.

diff --git a/docs/opengauss/umn/opengauss_01_0008.html b/docs/opengauss/umn/opengauss_01_0008.html index 2c42784df..9ffd46a0c 100644 --- a/docs/opengauss/umn/opengauss_01_0008.html +++ b/docs/opengauss/umn/opengauss_01_0008.html @@ -1,7 +1,7 @@

Instance Versions

-

Currently, GaussDB 8.103, 3.223, 3.222, 3.208, 3.103, 2.7, 2.3, 1.4, and 1.0 are supported.

+

Currently, GaussDB V2.0-8.102, V2.0-3.223, V2.0-3.222, and V2.0-3.208 are supported.

diff --git a/docs/opengauss/umn/opengauss_01_0018.html b/docs/opengauss/umn/opengauss_01_0018.html index 49553637a..d1f2b8c77 100644 --- a/docs/opengauss/umn/opengauss_01_0018.html +++ b/docs/opengauss/umn/opengauss_01_0018.html @@ -32,7 +32,7 @@

DB Engine Version

-

Currently, GaussDB 8.103, 3.223, 3.222, 3.208, 3.103, 2.7, 2.3, 1.4, and 1.0 are supported.

+

Currently, GaussDB V2.0-8.102, V2.0-3.223, V2.0-3.222, and V2.0-3.208 are supported.

DB Instance Type

diff --git a/docs/opengauss/umn/opengauss_01_0066.html b/docs/opengauss/umn/opengauss_01_0066.html index 7e874664c..7e6234720 100644 --- a/docs/opengauss/umn/opengauss_01_0066.html +++ b/docs/opengauss/umn/opengauss_01_0066.html @@ -4,7 +4,7 @@

Scenarios

You can use an instance-level automated backup to restore a GaussDB instance to a specified point in time.

You can restore data to a new instance.

-

Precautions

  • Only instances of version 2.1 or later can be restored to any point in time.
  • If nodes are being added, versions are being upgraded, or data is being restored to an existing instance, the instance cannot be restored a specific point in time.
  • If a DB instance is faulty or a CN is removed, archive logs cannot be generated and the instance cannot be restored to a specific point in time.
  • If you restore backup data to a new DB instance:
    • The DB engine and major version are the same as those of the original DB instance and cannot be changed.
    • The administrator password needs to be reset.
    +

    Precautions

    • Only instances of version 2.1 or later can be restored to any point in time.
    • Data from the time period of the following operations cannot be restored: nodes are being added to an instance, the instance version is being upgraded, or the instance data is being restored.
    • If a DB instance is faulty or a CN is removed, archive logs cannot be generated, and data from the affected time period cannot be restored.
    • If you restore backup data to a new DB instance:
      • The DB engine and major version are the same as those of the original DB instance and cannot be changed.
      • The administrator password needs to be reset.
    • If you restore backup data to the original DB instance, data on the original instance will be overwritten and the original DB instance will be unavailable during the restoration. Additionally, log archiving stops. After the restoration is complete, the Confirm Data Integrity button is displayed. Before clicking Confirm Data Integrity, you can restore data for multiple times. Once data integrity has been confirmed, any logs archived after the point in time data was restored from will be lost, but normal log archiving will be restored.
    • When a DB instance is deleted, all archive logs are deleted by default and cannot be retained. Data cannot be restored to a specific point in time after the DB instance is rebuilt.

    Procedure

    1. Log in to the management console.
    2. Click in the upper left corner and select a region and project.

      diff --git a/docs/opengauss/umn/opengauss_01_0071.html b/docs/opengauss/umn/opengauss_01_0071.html index 7d3eb93a3..f6b2c627d 100644 --- a/docs/opengauss/umn/opengauss_01_0071.html +++ b/docs/opengauss/umn/opengauss_01_0071.html @@ -606,7 +606,7 @@

      Online Sessions

      -

      Number of real-time online sessions

      +

      Real-time number of online sessions

      Distributed: all CNs + primary DN

      Centralized: all DNs

      diff --git a/docs/opengauss/umn/opengauss_faq_0010.html b/docs/opengauss/umn/opengauss_faq_0010.html index ad32b66dd..5f6740abe 100644 --- a/docs/opengauss/umn/opengauss_faq_0010.html +++ b/docs/opengauss/umn/opengauss_faq_0010.html @@ -1,7 +1,7 @@

      What Do I Do If Replay Speed of Standby Nodes Cannot Catch Up with Write Speed of Primary Nodes?

      -

      Symptom

      When workloads on a DB instance are heavy, the playback speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, logs are accumulated on the standby nodes. If a primary node is faulty, data restoration takes a long time and the database is unavailable, severely affecting system availability.

      +

      Symptom

      When workloads on a DB instance are heavy, the replay speed of standby nodes cannot catch up with write speed of primary nodes. After the system runs for a long time, logs are accumulated on the standby nodes. If a primary node is faulty, data restoration takes a long time and the database is unavailable, severely affecting system availability.

      Solution

      GaussDB provides ultimate RTO to minimize the data recovery time after a primary node is faulty and improve availability.

      To use ultimate RTO, submit an application by choosing in the upper right corner of the console.

      diff --git a/docs/opengauss/umn/opengauss_opti_0032.html b/docs/opengauss/umn/opengauss_opti_0032.html index d300a4400..32e326384 100644 --- a/docs/opengauss/umn/opengauss_opti_0032.html +++ b/docs/opengauss/umn/opengauss_opti_0032.html @@ -12,7 +12,7 @@

      Execution Plan Information

      In addition to configuring different display formats for execution plans, you can use different EXPLAIN syntax to display execution plan information in detail.

      • EXPLAIN statement: only generates an execution plan and does not execute. The statement indicates SQL statements.
      • EXPLAIN ANALYZE statement: generates and executes an execution plan, and displays the execution summary. Then actual execution time statistics are added, including the total elapsed time expended within each plan node (in milliseconds) and the total number of rows it actually returned.
      • EXPLAIN PERFORMANCE statement: generates and executes an execution plan, and displays all execution information.
      -

      To measure the run time cost of each node in the execution plan, the current execution of EXPLAIN ANALYZE or EXPLAIN PERFORMANCE adds profiling overhead to query execution. Running EXPLAIN ANALYZE or PERFORMANCE on a query sometimes takes longer time than executing the query normally. The amount of overhead depends on the nature of the query, as well as the platform being used. For details, see "SQL Reference" > "SQL Syntax" > "EXPLAIN" in GaussDB Development Guide (1.x).

      +

      To measure the run time cost of each node in the execution plan, the current execution of EXPLAIN ANALYZE or EXPLAIN PERFORMANCE adds profiling overhead to query execution. Running EXPLAIN ANALYZE or PERFORMANCE on a query sometimes takes longer time than executing the query normally. The amount of overhead depends on the nature of the query, as well as the platform being used. For details, see "SQL Reference" > "SQL Syntax" > "EXPLAIN" in GaussDB Developer Guide (1.x).

      Therefore, if a SQL statement is not finished after being running for a long time, run the EXPLAIN statement to view the execution plan and then locate the fault. If the SQL statement has been properly executed, run the EXPLAIN ANALYZE or EXPLAIN PERFORMANCE statement to check the execution plan and information to locate the fault.

      The EXPLAIN PERFORMANCE lightweight execution is consistent with EXPLAIN PERFORMANCE but greatly reduces the time spent on performance analysis.

      diff --git a/docs/opengauss/umn/opengauss_opti_0046.html b/docs/opengauss/umn/opengauss_opti_0046.html index e125a211a..7ada7ee9d 100644 --- a/docs/opengauss/umn/opengauss_opti_0046.html +++ b/docs/opengauss/umn/opengauss_opti_0046.html @@ -81,7 +81,7 @@ FROM store_sales;

      func_percent_1 is pushed down to DNs for quicker execution. (In TPC-DS 1000X, where three CNs and 18 DNs are used, the query efficiency is improved by over 100 times).

      -

      Functions That Do Not Support Pushdown

      The following describes the volatility of functions. The function variability in GaussDB is as follows:

      +

      Functions That Do Not Support Pushdown

      The following describes the volatility of functions. The function volatility in GaussDB is as follows:

      • IMMUTABLE

        Specifies that the function always returns the same result if the parameter values are the same.

      • STABLE

        Specifies that the function cannot modify the database, and that within a single table scan, it will consistently return the same result for the same parameter value, but its result varies by SQL statements.

      • VOLATILE

        Specifies that the function value can change in a single table scan and no optimization is performed.

        @@ -136,7 +136,7 @@ postgres=# CREATE TABLE sal_emp ( c1 integer[] ) DISTRIBUTE BY replication; 8 9 10
      postgres=# explain verbose select count ( c_custkey order by c_custkey) from customer1;
-                               
+
                          QUERY PLAN                                        
 ------------------------------------------------------------------ Aggregate  (cost=2.50..2.51 rows=1 width=8)
    Output: count(customer1.c_custkey ORDER BY customer1.c_custkey)
diff --git a/docs/opengauss/umn/opengauss_opti_0047.html b/docs/opengauss/umn/opengauss_opti_0047.html
index 40912d0e7..d0215d577 100644
--- a/docs/opengauss/umn/opengauss_opti_0047.html
+++ b/docs/opengauss/umn/opengauss_opti_0047.html
@@ -389,7 +389,7 @@
 create table sub_table(a int, b int); 
 select a from master_table group by a having a in (select a from sub_table);

      In this example, a correlated subquery is contained. To improve the query performance, you can change sub_table to a replication table and create an index on the a column.

      -

      Example 2: Modify the SELECT statement by changing the subquery to a JOIN relationship between the primary table and the parent query or modifying the subquery to improve the query performance. Ensure that the subquery to be used is semantically correct.

      +

      Example 2: Modify the SELECT statement by changing the subquery to a JOIN relationship between the main table and the parent query or modifying the subquery to improve the query performance. Ensure that the subquery to be used is semantically correct.

      explain (costs off)select * from master_table as t1 where t1.a in (select t2.a from sub_table as t2 where t1.a = t2.b); 
                         QUERY PLAN 
 ---------------------------------------------------------- 
diff --git a/docs/opengauss/umn/opengauss_opti_0052.html b/docs/opengauss/umn/opengauss_opti_0052.html
index df9dee211..8fd7d130c 100644
--- a/docs/opengauss/umn/opengauss_opti_0052.html
+++ b/docs/opengauss/umn/opengauss_opti_0052.html
@@ -12,7 +12,8 @@
 
      enable_nestloop=on
      
 
 
      Specifies how the optimizer uses Nest Loop Join. If this parameter is set to on, the optimizer preferentially uses Nest Loop Join. If it is set to off, the optimizer preferentially uses other methods, if any.
      
-
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
      
 
      SET enable_nestloop to off;
      
 
      You can determine whether to disable this function based on the actual requirements. Generally, among the three join modes (Nested Loop, Merge Join, and Hash Join), Nested Loop is suitable for scenarios with small data volume or indexes, and Hash Join is suitable for big data analysis.
      
 
@@ -20,7 +21,8 @@
 
      enable_bitmapscan=on
      
 
 
      Specifies whether the optimizer uses bitmap scanning. If the value is on, bitmap scanning is used. If the value is off, it is not used.
      
-
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
      
 
      SET enable_bitmapscan to off;
      
 
      The bitmap scan applies only in the query condition where a > 1 and b > 1 is used and indexes are created on columns a and b. It sometimes does not perform as well as index scan. During performance tuning, if the query performance is poor and bitmapscan operators are in the execution plan, set this parameter to off and check whether the performance is improved.
      
 
@@ -28,7 +30,8 @@
 
      enable_fast_query_shipping=on
      
 
 
      Specifies whether the optimizer uses a distribution framework. If its value is on, the execution plan is generated on both CNs and DNs. If the value is off, the distribution framework is used. The execution plan is generated on CNs and then sent to DNs for execution.
      
-
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
       NOTE: 
      If you only want to temporarily change the value of this parameter during the current database connection (or the current session), execute the following SQL statement:
      
+
      
 
      SET enable_fast_query_shipping to off;
      
 
 
@@ -39,7 +42,7 @@
 
 
      enable_hashjoin=on
      
 
-
      Specifies whether enable the optimizer's use of hash join plan types.
      
+
      Specifies whether to enable the optimizer's use of hash join plan types.
      
 
 
 
      enable_mergejoin=on
      
@@ -59,7 +62,7 @@
 
 
      enable_seqscan=on
      
 
-
      Specifies whether enable the optimizer's use of sequential scan plan types. It is impossible to completely suppress sequential scans, but setting this parameter to off allows the optimizer to choose other methods if available.
      
+
      Specifies whether to enable the optimizer's use of sequential scan plan types. It is impossible to completely suppress sequential scans, but setting this parameter to off allows the optimizer to choose other methods if available.
      
 
 
 
      enable_sort=on
      
@@ -69,7 +72,7 @@
 
 
      enable_broadcast=on
      
 
-
      Specifies whether enable the optimizer's use of data broadcast. In data broadcast, a large amount of data is transferred on the network. When the number of transmission nodes (stream) is large and the estimation is inaccurate, set this parameter to off and check whether the performance is improved.
      
+
      Specifies whether to enable the optimizer's use of data broadcast. In data broadcast, a large amount of data is transferred on the network. When the number of transmission nodes (stream) is large and the estimation is inaccurate, set this parameter to off and check whether the performance is improved.
      
 
 
 
      rewrite_rule
      
diff --git a/docs/opengauss/umn/opengauss_tips_0003.html b/docs/opengauss/umn/opengauss_tips_0003.html
index 9ae668ce5..980c2903a 100644
--- a/docs/opengauss/umn/opengauss_tips_0003.html
+++ b/docs/opengauss/umn/opengauss_tips_0003.html
@@ -18,7 +18,7 @@
    3. DELETE
      4. -
    4. Associated Query
      +
    5. Join Query
    6. Subqueries
      7. diff --git a/docs/opengauss/umn/opengauss_tips_0006.html b/docs/opengauss/umn/opengauss_tips_0006.html index c8a4ff984..c3df4f85a 100644 --- a/docs/opengauss/umn/opengauss_tips_0006.html +++ b/docs/opengauss/umn/opengauss_tips_0006.html @@ -50,7 +50,7 @@

      Any precision

      -

      NUMERIC/DEMICAL

      +

      NUMERIC/DECIMAL

      Floating point

      diff --git a/docs/opengauss/umn/opengauss_tips_0012.html b/docs/opengauss/umn/opengauss_tips_0012.html index 735b19630..59db9037e 100644 --- a/docs/opengauss/umn/opengauss_tips_0012.html +++ b/docs/opengauss/umn/opengauss_tips_0012.html @@ -36,7 +36,7 @@

      Any precision

      -

      NUMERIC/DEMICAL

      +

      NUMERIC/DECIMAL

      Yes

      diff --git a/docs/opengauss/umn/opengauss_tips_0013.html b/docs/opengauss/umn/opengauss_tips_0013.html index 34de2182b..709f4778c 100644 --- a/docs/opengauss/umn/opengauss_tips_0013.html +++ b/docs/opengauss/umn/opengauss_tips_0013.html @@ -30,7 +30,7 @@
    7. For a distributed hash table, the primary key and unique index must contain distribution keys.
    8. Properly design composite indexes to avoid redundancy.

      For example, if an index has been created for (a, b, c), you shall not create an index for (a), (b), (c), (a, b), or (b, c) independently.

      If only the filtering condition of the a column is used for a query, composite indexes are used for the query as well.

    9. Do not create multiple unique indexes for a single table.

      Maintaining multiple unique indexes at the same time generates more overheads than maintaining a multi-column unique index. If multiple unique indexes are equivalent to a multi-column unique index in service logic, a multi-column unique index shall be preferred.

      -
    10. A composite index contains up to 5 columns.
    11. The total length of the combined character string of a composite index cannot exceed 200.
    12. Index (including single-column and composite indexes) columns must be NOT NULL.
    13. The efficiency of maintaining indexes created for the same column is different. Columns of the number type are better than those of the character type and other data types. Therefore, it is recommended that columns such as IDs and time for creating indexes be stored as data of the number type.
    14. You are advised to create an index on the associated column.

      HASH JOIN is supported, whereas NESTLOOP JOIN may be used for join operations if the rescan cost is low (for example, the internal table is small). If the NESTLOOP JOIN plan can be viewed by executing EXPLAIN, you can create indexes on joined columns to improve the efficiency of NESTLOOP JOIN.

      +
    15. A composite index contains up to 5 columns.
    16. The total length of the combined character string of a composite index cannot exceed 200.
    17. Index (including single-column and composite indexes) columns must be NOT NULL.
    18. The efficiency of maintaining indexes created for the same column is different. Columns of the number type are better than those of the character type and other data types. Therefore, it is recommended that columns such as IDs and time for creating indexes be stored as data of the number type.
    19. You are advised to create an index on the join column.

      HASH JOIN is supported, whereas NESTLOOP JOIN may be used for join operations if the rescan cost is low (for example, the internal table is small). If the NESTLOOP JOIN plan can be viewed by executing EXPLAIN, you can create indexes on joined columns to improve the efficiency of NESTLOOP JOIN.

diff --git a/docs/opengauss/umn/opengauss_tips_0018.html b/docs/opengauss/umn/opengauss_tips_0018.html index 7059f6aec..217876935 100644 --- a/docs/opengauss/umn/opengauss_tips_0018.html +++ b/docs/opengauss/umn/opengauss_tips_0018.html @@ -19,7 +19,7 @@

ANALYZE;

-- Analyze the specified table.

ANALYZE tablename;

-
  • This event is triggered when the number of rows added or deleted at a specified interval or in a table reaches a specified value by using AUTO VACCUUM. The interval and addition/deletion ratio can be configured through the GUC parameters.
    • +
  • This event is triggered when the number of rows added or deleted at a specified interval or in a table reaches a specified value by using AUTO VACUUM. The interval and addition/deletion ratio can be configured through the GUC parameters.

    • diff --git a/docs/opengauss/umn/opengauss_tips_0021.html b/docs/opengauss/umn/opengauss_tips_0021.html index 38a6a73c6..d043e540b 100644 --- a/docs/opengauss/umn/opengauss_tips_0021.html +++ b/docs/opengauss/umn/opengauss_tips_0021.html @@ -2,7 +2,7 @@

    DELETE

    • LIMIT cannot be used in the DELETE statement. The WHERE condition should be used to specify the target row to be deleted.
    • In GMT-free mode, cross-node transactions are not allowed. Therefore, when deleting a data table distributed by hash, you must specify the equal condition in the WHERE condition for the distributed columns.
    • Deleting multiple tables is not supported.

      Multi-table deletion indicates that multiple tables are deleted in a single SQL statement.

      -
    • The DELETE statement must contain the WHERE clause to avoid full table scanning.
    • Do not use the ORDER BY or GROUP BY clause in the DELETE statement to avoid unnecessary sorting.
    • Use TRUNCATE instead of DELETE to clear a table.

      TRUNCATE creates a new physical file and physically deletes the original file when the transaction ends to clear the disk space. However, the DELETE statement marks data in the table and does not clear the disk space until the VACCUUM FULL phase.

      +
    • The DELETE statement must contain the WHERE clause to avoid full table scanning.
    • Do not use the ORDER BY or GROUP BY clause in the DELETE statement to avoid unnecessary sorting.
    • Use TRUNCATE instead of DELETE to clear a table.

      TRUNCATE creates a new physical file and physically deletes the original file when the transaction ends to clear the disk space. However, the DELETE statement marks data in the table and does not clear the disk space until the VACUUM FULL phase.

    • If a DELETE statement is executed on a table that has a primary key or index, the WHERE condition must be used together with the primary key or index to improve execution efficiency.
    diff --git a/docs/opengauss/umn/opengauss_tips_0022.html b/docs/opengauss/umn/opengauss_tips_0022.html index 470a9af9b..a6d37257e 100644 --- a/docs/opengauss/umn/opengauss_tips_0022.html +++ b/docs/opengauss/umn/opengauss_tips_0022.html @@ -1,14 +1,14 @@ -

    Associated Query

    +

    Join Query

    • The nesting depth of multi-table association must be less than 8.

      If the association nesting is too deep, slow SQL statements may be generated. You need to optimize the association nesting at the service layer.

      -
    • When tables are associated for query, the join condition (ON) of each table must be specified to avoid Cartesian product.

      For example, in MySQL, JOIN is equivalent to CROSS JOIN and INNER JOIN. However, in the SQL standards, JOIN is equivalent to INNER JOIN only and must be used together with the ON condition.

      +
    • When tables are joined for query, the join condition (ON) of each table must be specified to avoid Cartesian product.

      For example, in MySQL, JOIN is equivalent to CROSS JOIN and INNER JOIN. However, in the SQL standards, JOIN is equivalent to INNER JOIN only and must be used together with the ON condition.

      Negative examples: The following query statements return a Cartesian product:

      SELECT * FROM TABLE1 A , TABLE2 B;

      SELECT * FROM TABLE1 A JOIN TABLE2 B ON 1=1;

      -
    • The JOIN mode must be specified based on the SQL standards during association. Do not use the JOIN keyword directly. Instead, use CROSS JOIN, INNER JOIN, LEFT JOIN, or RIGHT JOIN.
    • When multiple tables are associated for query, aliases shall be added to the tables to ensure that the statement logic is clear and easy to maintain.
    • Different columns have different comparison overheads. You are advised to use a field type with high efficiency for associated columns.

      The comparison efficiency of the numeric type is much higher than that of the string type.

      +
    • The JOIN mode must be specified based on the SQL standards during association. Do not use the JOIN keyword directly. Instead, use CROSS JOIN, INNER JOIN, LEFT JOIN, or RIGHT JOIN.
    • When multiple tables are joined for query, aliases shall be added to the tables to ensure that the statement logic is clear and easy to maintain.
    • Different columns have different comparison overheads. You are advised to use a field type with high efficiency for join columns.

      The comparison efficiency of the numeric type is much higher than that of the string type.

      The comparison efficiency of integers is much higher than that of numeric and floating-point types.

      -
    • The associated columns must be of the same data type to avoid the impact of implicit type conversion on the execution efficiency.
    • You are advised use table association, instead of nested subqueries, because subqueries will generate temporary tables and greatly affect SQL performance.
    • If a large number of NULL values exist in the associated columns, you are advised to add the IS NOT NULL condition to the WHERE condition to improve the execution efficiency.
    +
  • The join columns must be of the same data type to avoid the impact of implicit type conversion on the execution efficiency.
  • You are advised use table association, instead of nested subqueries, because subqueries will generate temporary tables and greatly affect SQL performance.
  • If a large number of NULL values exist in the join columns, you are advised to add the IS NOT NULL condition to the WHERE condition to improve the execution efficiency.
    • diff --git a/docs/opengauss/umn/opengauss_tips_0024.html b/docs/opengauss/umn/opengauss_tips_0024.html index f658efad0..8a970a92d 100644 --- a/docs/opengauss/umn/opengauss_tips_0024.html +++ b/docs/opengauss/umn/opengauss_tips_0024.html @@ -8,7 +8,7 @@

    You are advised to modify the statement so that it can be executed on a single node. If the statement needs to be executed on multiple nodes, add a hint, for example, insert /*+ multinode */ into t values(3,3),(1,1);

    It is recommended that application_type is set to perfect_sharding_type in the JDBC connection string in the development phase. In this way, errors are reported for all cross-node read and write SQL statements, prompting developers to optimize statements as soon as possible.

    -
  • Large object operations do not support transactions.

    Large object operations include creating and deleting DATABASE, ANAYLIZE, and VACCUM jobs.

    +
  • Large object operations do not support transactions.

    Large object operations include creating and deleting DATABASE, ANAYLIZE, and VACUUM jobs.

  • Do not combine multiple SQL statements into one statement when accessing the database through JDBC

    When multiple statements are combined into one statement that contains object operations, if the intermediate object operation fails, a new transaction is started to execute subsequent statements.

    Example: The following statement does not meet the requirements.