From 4c80f035b1ff517a9d976b6d39cfca409d2fefbb Mon Sep 17 00:00:00 2001 From: Anders Kaseorg Date: Tue, 22 Feb 2022 23:34:40 -0800 Subject: [PATCH] docs: Update documentation on AddIndexConcurrently. Signed-off-by: Anders Kaseorg --- docs/subsystems/schema-migrations.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/subsystems/schema-migrations.md b/docs/subsystems/schema-migrations.md index 0daf18de6e..e289777328 100644 --- a/docs/subsystems/schema-migrations.md +++ b/docs/subsystems/schema-migrations.md @@ -54,13 +54,12 @@ migrations. to the table, performing data backfills, or building indexes. We have a `zerver/lib/migrate.py` library to help with adding columns and backfilling data. -- **Adding indexes** Regular `CREATE INDEX` SQL (corresponding to Django's - `AddIndex` operation) locks writes to the affected table. This can be +- **Adding indexes**. Django's regular `AddIndex` operation (corresponding + to `CREATE INDEX` in SQL) locks writes to the affected table. This can be problematic when dealing with larger tables in particular and we've - generally preferred to use `CREATE INDEX CONCURRENTLY` to allow the index - to be built while the server is active. While in historical migrations - we've used `RunSQL` directly, newer versions of Django add the corresponding - operation `AddIndexConcurrently` and thus that's what should normally be used. + generally preferred to use `AddIndexConcurrently` (corresponding to + `CREATE INDEX CONCURRENTLY`) to allow the index to be built while + the server is active. - **Atomicity**. By default, each Django migration is run atomically inside a transaction. This can be problematic if one wants to do something in a migration that touches a lot of data and would best