diff options
Diffstat (limited to 'doc/development/database_review.md')
| -rw-r--r-- | doc/development/database_review.md | 14 |
1 files changed, 10 insertions, 4 deletions
diff --git a/doc/development/database_review.md b/doc/development/database_review.md index 57cdc2135aa..39236ab1910 100644 --- a/doc/development/database_review.md +++ b/doc/development/database_review.md @@ -78,7 +78,8 @@ and details for a database reviewer: - Format any queries with a SQL query formatter, for example with [sqlformat.darold.net](http://sqlformat.darold.net). - Consider providing query plans via a link to [explain.depesz.com](https://explain.depesz.com) or another tool instead of textual form. - For query changes, it is best to provide the SQL query along with a plan *before* and *after* the change. This helps to spot differences quickly. -- When providing query plans, make sure to use good parameter values, so that the query executed is a good example and also hits enough data. Usually, the `gitlab-org` namespace (`namespace_id = 9970`) and the `gitlab-org/gitlab-ce` project (`project_id = 13083`) provides enough data to serve as a good example. +- When providing query plans, make sure to use good parameter values, so that the query executed is a good example and also hits enough data. + - Usually, the `gitlab-org` namespace (`namespace_id = 9970`) and the `gitlab-org/gitlab-foss` (`project_id = 13083`) or the `gitlab-org/gitlab` (`project_id = 278964`) projects provide enough data to serve as a good example. ### How to review for database @@ -94,17 +95,22 @@ and details for a database reviewer: - Check queries timing (If any): Queries executed in a migration need to fit comfortably within `15s` - preferably much less than that - on GitLab.com. - Check [background migrations](background_migrations.md): - - For data migrations, establish a time estimate for execution + - Establish a time estimate for execution on GitLab.com. - They should only be used when migrating data in larger tables. - If a single `update` is below than `1s` the query can be placed directly in a regular migration (inside `db/migrate`). - Review queries (for example, make sure batch sizes are fine) - - Establish a time estimate for execution - Because execution time can be longer than for a regular migration, it's suggested to treat background migrations as post migrations: place them in `db/post_migrate` instead of `db/migrate`. Keep in mind that post migrations are executed post-deployment in production. - Check [timing guidelines for migrations](#timing-guidelines-for-migrations) +- Check migrations are reversible and implement a `#down` method +- Check data migrations: + - Establish a time estimate for execution on GitLab.com. + - Depending on timing, data migrations can be placed on regular, post-deploy or background migrations. + - Data migrations should be reversible too or come with a description of how to reverse, when possible. + This applies to all types of migrations (regular, post-deploy, background). - Query performance - Check for any obviously complex queries and queries the author specifically points out for review (if any) @@ -120,7 +126,7 @@ and details for a database reviewer: pipeline](https://ops.gitlab.net/gitlab-com/gl-infra/gitlab-restore/postgres-gprd) in order to establish a proper testing environment. -### Timing guidelines for migrations +### Timing guidelines for migrations In general, migrations for a single deploy shouldn't take longer than 1 hour for GitLab.com. The following guidelines are not hard rules, they were |