- 最新
- 投票最多
- 评论最多
Consider table partitioning to split the large table into multiple smaller tables based on a column value like date. This makes queries and maintenance easier to manage.
For optimal performance, aim to have partitions in the 100s of GB size range. Too many small partitions can impact performance, while too few large partitions makes maintenance difficult.
Monitor disk usage of temporary files and consider increasing maintenance_work_mem and work_mem for queries creating large temporary results. This allocates more memory and reduces disk usage.
Aurora PostgreSQL does not support table compression directly but you can explore columnar storage formats like Parquet for analytics workloads requiring compression.
Refer to the AWS documentation for the latest storage limits of Aurora database instances. Consider resizing to a larger instance type if you need more storage capacity than currently available.
Monitor disk usage trends over time to understand growth and proactively plan for capacity needs. Check the AWS documentation for options to auto-scale storage capacity if needed.
相关内容
AWS 官方已更新 1 年前- AWS 官方已更新 2 年前
Thank you. So, does it mean that we can't compress the historical partitions in aurora postgres like we have the flexibility to do in other databases.
Saw the documentation and the storage limit for aurora postgres appears to be ~128TB and we have individual table which will grow till ~25-30TB and we may easily hit the limit.
I came across few blogs explaining TOAST compression technique, which compresses varchar and text columns using pglz4 and lz4. Out of that lz4 appears to be more effective. And it means we can be able to compress all the varchar columns using lz4 algorithm, which will compress all the partitions columns (not tried if we will be able to do it only on specific historic partition). However, can you please suggest, if this is advisable method?