summaryrefslogtreecommitdiff
path: root/doc/development/insert_into_tables_in_batches.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/development/insert_into_tables_in_batches.md')
-rw-r--r--doc/development/insert_into_tables_in_batches.md4
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/development/insert_into_tables_in_batches.md b/doc/development/insert_into_tables_in_batches.md
index 5fe37a95b59..cfa0c862471 100644
--- a/doc/development/insert_into_tables_in_batches.md
+++ b/doc/development/insert_into_tables_in_batches.md
@@ -1,7 +1,7 @@
---
stage: Enablement
group: Database
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
description: "Sometimes it is necessary to store large amounts of records at once, which can be inefficient
when iterating collections and performing individual `save`s. With the arrival of `insert_all`
in Rails 6, which operates at the row level (that is, using `Hash`es), GitLab has added a set
@@ -101,7 +101,7 @@ performance impact this might have on your code. There is a trade-off between th
### Handling duplicate records
-NOTE: **Note:**
+NOTE:
This parameter applies only to `bulk_insert!`. If you intend to update existing
records, use `bulk_upsert!` instead.