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
Now that we have leader_preference in tablespace groups, and there are more geo-partitioned use-cases coming up where customers are trying to read/write only to a specific region partition, we should enhance the SqlGeopartitioned workload to do reads/writes only to the connected "region" instead of randomly picking a region based on the modulus of the number of overall partitions.
E.g.
Consider the case where you have highly distributed regions:
ap-northeast-1
eu-west-1
us-east-1
In a geo-partitioned workload, where "fast" writes are required, you could set up a table that is comprised of multiple partitions that belong to 1 region only.
E.g.
As it happens right now in SqlGeopartitionedWorkload, these would be set up as different partitions, but ultimately the choice of which region is written or read by the workload comes down to a simply key % num_partitions choice. While useful, it doesn't illustrate the power that could be shown by allowing the connection to determine which region to read/write from.
The text was updated successfully, but these errors were encountered:
Now that we have leader_preference in tablespace groups, and there are more geo-partitioned use-cases coming up where customers are trying to read/write only to a specific region partition, we should enhance the SqlGeopartitioned workload to do reads/writes only to the connected "region" instead of randomly picking a region based on the modulus of the number of overall partitions.
E.g.
Consider the case where you have highly distributed regions:
In a geo-partitioned workload, where "fast" writes are required, you could set up a table that is comprised of multiple partitions that belong to 1 region only.
E.g.
As it happens right now in SqlGeopartitionedWorkload, these would be set up as different partitions, but ultimately the choice of which region is written or read by the workload comes down to a simply key % num_partitions choice. While useful, it doesn't illustrate the power that could be shown by allowing the connection to determine which region to read/write from.
The text was updated successfully, but these errors were encountered: