docs: Update documentation on AddIndexConcurrently.

Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
Anders Kaseorg
2022-02-22 23:34:40 -08:00
committed by Tim Abbott
parent 80def8d2c2
commit 4c80f035b1

View File

@@ -54,13 +54,12 @@ migrations.
to the table, performing data backfills, or building indexes. We to the table, performing data backfills, or building indexes. We
have a `zerver/lib/migrate.py` library to help with adding columns have a `zerver/lib/migrate.py` library to help with adding columns
and backfilling data. and backfilling data.
- **Adding indexes** Regular `CREATE INDEX` SQL (corresponding to Django's - **Adding indexes**. Django's regular `AddIndex` operation (corresponding
`AddIndex` operation) locks writes to the affected table. This can be 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 problematic when dealing with larger tables in particular and we've
generally preferred to use `CREATE INDEX CONCURRENTLY` to allow the index generally preferred to use `AddIndexConcurrently` (corresponding to
to be built while the server is active. While in historical migrations `CREATE INDEX CONCURRENTLY`) to allow the index to be built while
we've used `RunSQL` directly, newer versions of Django add the corresponding the server is active.
operation `AddIndexConcurrently` and thus that's what should normally be used.
- **Atomicity**. By default, each Django migration is run atomically - **Atomicity**. By default, each Django migration is run atomically
inside a transaction. This can be problematic if one wants to do 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 something in a migration that touches a lot of data and would best