|
Define large. IMO, I don’t partition until 750M to 1B rows. Maybe 500M is the table is heavily used or very wide. Partitioning under those row counts without working knowledge can hinder performance. From: srinivasan s <srinioracledba7@xxxxxxxxx> Hello everyone, I hope you are all doing well. I am seeking guidance on how to implement partitioning in PostgreSQL. We have a large table that currently does not have any partitioning, and we have two requirements for removing old data from this table. We are looking to create a new table with partitioning. 1. The first requirement is to delete all records from the table that are older than 18 months. I believe we can achieve this by using range partitioning on the timestamp column. 2. The second requirement is to remove data from the table when a user leaves the organization. We have the account ID and user ID in the same table. Could someone please offer guidance on selecting the appropriate partitioning method (range, sub-partition, or composite)? Additionally, not all queries use the timestamp column in the WHERE condition. Is it mandatory to use the partition key in the WHERE condition to benefit from partitioning? Can we create a composite index that combines the partition key
column with other columns used in the WHERE clause? Would this be beneficial? Thank you. |
