Updated on 2024-03-13 GMT+08:00
Cluster Performance
- Lock Wait Detection
- During SQL Execution, a Table Deadlock Occurs and An Error Stating LOCK_WAIT_TIMEOUT Is Reported
- Error "abort transaction due to concurrent update" Is Reported During SQL Execution
- Solution to High Disk Usage and Cluster Read-Only
- SQL Execution Is Slow with Low Performance and Sometimes Does Not End After a Long Period of Time
- Data Skew Causes Slow SQL Statement Execution and Operations Fail on Large Tables
- Table Size Does not Change After VACUUM FULL Is Executed on the Table
- VACUUM Is Executed After Table Data Deletion, But the Space Is Not Released
- Error LOCK_WAIT_TIMEOUT Is Reported When VACUUM FULL Is Executed
- VACUUM FULL Is Slow
- Table Bloating Causes Slow SQL Query and Failed Data Loading on the GUI
- Memory Overflow Occurs in a Cluster
- Statements with User-defined Functions Cannot Be Pushed Down
- Column-Store Tables Cannot Be Updated or Table Bloat Occurs
- Table Bloat Occurs After Data Is Inserted into a Column-Store Table for Multiple Times
- Writing Data to GaussDB(DWS) Is Slow and Client Data Is Stacked
- Low Query Efficiency
- Poor Query Performance Due to the Lack of Statistics
- Execution of SQL Statements with NOT IN and NOT EXISTS Is Slow Due to Nested Loops in Execution Plans
- SQL Query Is Slow Because Partitions Are Not Pruned
- Optimizer Uses Nested Loop Due to the Small Estimated Number of Rows and the Performance Deteriorates
- SQL Statements Contain the in Constant and No Result Is Returned After SQL Statement Execution
- Performance of Single-Table Point Query Is Poor
- CCN Queuing Under Dynamic Load Management
- Performance Deterioration Due to Data Bloat
- Slow Performance Caused by Too Many Small CUs in Column Storage
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.
The system is busy. Please try again later.
