summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMark Chao <mchao@gitlab.com>2018-07-11 11:33:49 +0800
committerMark Chao <mchao@gitlab.com>2018-07-11 14:38:29 +0800
commit2be54f1bbfc9cfa1e07a88ea581508f251c09853 (patch)
tree5fe15f05d1a34232b5a484e81c8355e582692592
parentc2a0a3ab1aed9814c1044c753b3f31b29b6142b1 (diff)
downloadgitlab-ce-2be54f1bbfc9cfa1e07a88ea581508f251c09853.tar.gz
Fix doc for large table column rename
-rw-r--r--doc/development/what_requires_downtime.md4
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.