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
Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
Most temporal sql query use shard_id as condition, for postgres database partition by hash is nice for large table.
Maybe some table partition number could be number of shards.
Thank you for your feature request! It's great to hear about your interest in using table partitioning with Temporal.
While Temporal doesn't currently directly support table partitioning, you can explore other ways to achieve similar performance benefits. Here are a few suggestions:
Use Temporal's shard_id: You can leverage Temporal's shard_id in your SQL queries to distribute queries across different shards. This can improve query performance and scalability, especially with large datasets.
Implement a custom partitioning strategy: You can develop your own partitioning mechanism outside of Temporal. You could create a mapping between Temporal shard IDs and your chosen partitioning key, and use this mapping to distribute data and queries.
Please let us know if you have any further questions. We are always happy to help!
Is your feature request related to a problem? Please describe.
No.
Describe the solution you'd like
Most temporal sql query use shard_id as condition, for postgres database partition by hash is nice for large table.
Maybe some table partition number could be number of shards.
Describe alternatives you've considered
No.
Additional context
https://www.postgresql.org/docs/current/ddl-partitioning.html
The text was updated successfully, but these errors were encountered: