Mirror
/
zulip
mirror of https://github.com/zulip/zulip.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/subsystems/schema-migrations.md
View File

@ -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