mirror of
				https://github.com/zulip/zulip.git
				synced 2025-11-04 05:53:43 +00:00 
			
		
		
		
	docs: Update documentation on AddIndexConcurrently.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit is contained in:
		
				
					committed by
					
						
						Tim Abbott
					
				
			
			
				
	
			
			
			
						parent
						
							80def8d2c2
						
					
				
				
					commit
					4c80f035b1
				
			@@ -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
 | 
				
			||||||
 
 | 
				
			|||||||
		Reference in New Issue
	
	Block a user