diff options
author | Mark Chao <mchao@gitlab.com> | 2018-07-11 06:33:49 +0300 |
---|---|---|
committer | Mark Chao <mchao@gitlab.com> | 2018-07-11 09:38:29 +0300 |
commit | 2be54f1bbfc9cfa1e07a88ea581508f251c09853 (patch) | |
tree | 5fe15f05d1a34232b5a484e81c8355e582692592 /doc | |
parent | c2a0a3ab1aed9814c1044c753b3f31b29b6142b1 (diff) |
Fix doc for large table column rename
Diffstat (limited to 'doc')
-rw-r--r-- | doc/development/what_requires_downtime.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md index 47396666879..b668c9de6a0 100644 --- a/doc/development/what_requires_downtime.md +++ b/doc/development/what_requires_downtime.md @@ -198,14 +198,14 @@ And that's it, we're done! ## Changing The Schema For Large Tables While `change_column_type_concurrently` and `rename_column_concurrently` can be -used for changing the schema of a table without downtime it doesn't work very +used for changing the schema of a table without downtime, it doesn't work very well for large tables. Because all of the work happens in sequence the migration can take a very long time to complete, preventing a deployment from proceeding. They can also produce a lot of pressure on the database due to it rapidly updating many rows in sequence. To reduce database pressure you should instead use -`change_column_type_using_background_migration` or `rename_column_concurrently` +`change_column_type_using_background_migration` or `rename_column_using_background_migration` when migrating a column in a large table (e.g. `issues`). These methods work similarly to the concurrent counterparts but uses background migration to spread the work / load over a longer time period, without slowing down deployments. |