external
/
citus
mirror of https://github.com/citusdata/citus.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix typos

pull/7638/head
Jelte Fennema-Nio 2024-06-27 12:59:59 +02:00
parent c3d1ad3f9d
commit fa56e38033
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
src/backend/distributed/README.md
View File

@ -2390,7 +2390,7 @@ Cost and capacity are vague on purpose, this way users can choose their own
way to determine cost of a shard group, but **in practice "cost" is usually way to determine cost of a shard group, but **in practice "cost" is usually
disk size** (because `by_disk_size` is the default rebalance strategy). disk size** (because `by_disk_size` is the default rebalance strategy).
Capacity is almost always set to 1, because almost all Citus clusters are Capacity is almost always set to 1, because almost all Citus clusters are
homogenous (they contain the same nodes, except for maybe the coordinator). The homogeneous (they contain the same nodes, except for maybe the coordinator). The
main usage for "Is a shard group allowed on a certain node?" is to be able to pin a main usage for "Is a shard group allowed on a certain node?" is to be able to pin a
specific shard group to a specific node. specific shard group to a specific node.
@ -2432,7 +2432,7 @@ Of course, the devil is in the details though.
### When is the balance better? ### When is the balance better?
The main way to determine if the balance is better is by comparing the The main way to determine if the balance is better is by comparing the
utilization of node A and B, before and ofter the move and seeing if they are utilization of node A and B, before and after the move and seeing if they are
net closer to the average utilization of the nodes in the cluster. The easiest net closer to the average utilization of the nodes in the cluster. The easiest
way to explain this is with a simple example: way to explain this is with a simple example:
@ -2459,8 +2459,8 @@ moving shards around isn't free.
this threshold is that these small differences in utilization are not this threshold is that these small differences in utilization are not
necessarily problematic and might very well resolve automatically over time. For example, consider a scenario in which necessarily problematic and might very well resolve automatically over time. For example, consider a scenario in which
one shard gets mostly written in during the weekend, while another one during one shard gets mostly written in during the weekend, while another one during
the week. Moving shards on monday and that you then have to move back on the week. Moving shards on Monday and that you then have to move back on
friday is not very helpful given the overhead of moving data around. Friday is not very helpful given the overhead of moving data around.
- `improvement_threshold`: This is used in cases where a shard group move from - `improvement_threshold`: This is used in cases where a shard group move from
node A to B swaps which node now has the highest utilization (so afterwards B node A to B swaps which node now has the highest utilization (so afterwards B
will have higher utilization than A). As described above this can still will have higher utilization than A). As described above this can still
@ -2572,7 +2572,7 @@ the full rebalance, and each of its tasks are separate shard group moves.
### Parallel background task execution ### Parallel background task execution
A big benefit of the bacground task infrastructure is that it can execute tasks A big benefit of the background task infrastructure is that it can execute tasks
and jobs in parallel. This can make rebalancing go much faster especially in and jobs in parallel. This can make rebalancing go much faster especially in
clusters with many nodes. To ensure that we're not doing too many tasks in clusters with many nodes. To ensure that we're not doing too many tasks in
parallel though we have a few ways to limit concurrency: parallel though we have a few ways to limit concurrency: