Case: Modifying a Partitioned Table
Symptom
In the following simple SQL statements, the performance bottlenecks exist in the scan operation on the normal_date table.
1 2 3 4 5 6 7 |
QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------- Seq Scan on normal_date (cost=0.00..259.00 rows=30 width=12) (actual time=0.100..3.466 rows=30 loops=1) Filter: (("time" >= '2022-09-01 00:00:00'::timestamp without time zone) AND ("time" <= '2022-10-01 00:00:00'::timestamp without time zone)) Rows Removed by Filter: 9970 Total runtime: 3.587 ms (4 rows) |
Optimization Analysis
Obviously, there are date features in the time column of table data in the service layer, and this meet the features of a partitioned table. Replan the table definition of the normal_date table. Set the time column as a partition key, and month as an interval unit. Define the partitioned table normal_date_part. The modified result is as follows, and the performance is improved by nearly 10 times.
1 2 3 4 5 6 7 8 9 10 |
QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------------------- Partition Iterator (cost=0.00..480.00 rows=30 width=12) (actual time=0.038..0.085 rows=30 loops=1) Iterations: 2 -> Partitioned Seq Scan on normal_date_part (cost=0.00..480.00 rows=30 width=12) (actual time=0.049..0.063 rows=30 loops=2) Filter: (("time" >= '2022-09-01 00:00:00'::timestamp without time zone) AND ("time" <= '2022-10-01 00:00:00'::timestamp without time zone)) Rows Removed by Filter: 31 Selected Partitions: 3..4 Total runtime: 0.360 ms (7 rows) |
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot