You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repository and believe that this is not a duplicate.
Summary 💡
Add support for declaring tables as PARTITIONED BY RANGE/HASH/LIST ("id"), along with creating a default partition.
Initially support partition key being the ID primary key
Handle unique constraint limitations that come with partitions.
Add API method for detaching the default partition, creating a new default, and reattaching the old default with an appropriate range. This will enable creating partitions on demand at a constant interval, without having a partition key be a timestamp.
Motivation 🔦
Partitioning enables us to delete old data in bulk fast. Deleting data from big tables takes a very long time so we partition the data by date (technically by ID as explained above). This way we can delete data from a single partition in a matter of seconds.
Thanks!
The text was updated successfully, but these errors were encountered:
Hi, team. This issue has been open for 2 years and it looks there is some interest to it (14 reactions).
My team is also interested in this feature, and we're interested in contributing to it. Is this something you'd be willing to accept as a contribution?
Summary 💡
PARTITIONED BY RANGE/HASH/LIST ("id")
, along with creating a default partition.Motivation 🔦
Partitioning enables us to delete old data in bulk fast. Deleting data from big tables takes a very long time so we partition the data by date (technically by ID as explained above). This way we can delete data from a single partition in a matter of seconds.
Thanks!
The text was updated successfully, but these errors were encountered: