Commit d9742b9c authored by Russell Dickenson's avatar Russell Dickenson

Merge branch 'eread/switch-from-html-to-markdown-for-code' into 'master'

Switch from inline HTML to Markdown for code in topic

See merge request gitlab-org/gitlab!72468
parents 94a652ed 206009a2
...@@ -66,9 +66,9 @@ The execution of the query can be largely broken down into three steps: ...@@ -66,9 +66,9 @@ The execution of the query can be largely broken down into three steps:
1. The database sorts the `issues` rows in memory by `created_at` and returns `LIMIT 20` rows to 1. The database sorts the `issues` rows in memory by `created_at` and returns `LIMIT 20` rows to
the end-user. For large groups, this final step requires both large memory and CPU resources. the end-user. For large groups, this final step requires both large memory and CPU resources.
<details> Execution plan for this DB query:
<summary>Expand this sentence to see the execution plan for this DB query.</summary>
<pre><code> ```sql
Limit (cost=90170.07..90170.12 rows=20 width=1329) (actual time=967.597..967.607 rows=20 loops=1) Limit (cost=90170.07..90170.12 rows=20 width=1329) (actual time=967.597..967.607 rows=20 loops=1)
Buffers: shared hit=239127 read=3060 Buffers: shared hit=239127 read=3060
I/O Timings: read=336.879 I/O Timings: read=336.879
...@@ -106,8 +106,7 @@ The execution of the query can be largely broken down into three steps: ...@@ -106,8 +106,7 @@ The execution of the query can be largely broken down into three steps:
Planning Time: 7.750 ms Planning Time: 7.750 ms
Execution Time: 967.973 ms Execution Time: 967.973 ms
(36 rows) (36 rows)
</code></pre> ```
</details>
The performance of the query depends on the number of rows in the database. The performance of the query depends on the number of rows in the database.
On average, we can say the following: On average, we can say the following:
...@@ -240,9 +239,9 @@ to make the query execute efficiently: ...@@ -240,9 +239,9 @@ to make the query execute efficiently:
"idx_issues_on_project_id_and_created_at_and_id" btree (project_id, created_at, id) "idx_issues_on_project_id_and_created_at_and_id" btree (project_id, created_at, id)
``` ```
<details> The SQL query:
<summary>Expand this sentence to see the SQL query.</summary>
<pre><code> ```sql
SELECT "issues".* SELECT "issues".*
FROM FROM
(WITH RECURSIVE "array_cte" AS MATERIALIZED (WITH RECURSIVE "array_cte" AS MATERIALIZED
...@@ -353,8 +352,7 @@ SELECT (records).* ...@@ -353,8 +352,7 @@ SELECT (records).*
FROM "recursive_keyset_cte" AS "issues" FROM "recursive_keyset_cte" AS "issues"
WHERE (COUNT <> 0)) issues -- filtering out the initializer row WHERE (COUNT <> 0)) issues -- filtering out the initializer row
LIMIT 20 LIMIT 20
</code></pre> ```
</details>
### Using the `IN` query optimization ### Using the `IN` query optimization
...@@ -466,9 +464,9 @@ Gitlab::Pagination::Keyset::InOperatorOptimization::QueryBuilder.new( ...@@ -466,9 +464,9 @@ Gitlab::Pagination::Keyset::InOperatorOptimization::QueryBuilder.new(
).execute.limit(20) ).execute.limit(20)
``` ```
<details> The SQL query:
<summary>Expand this sentence to see the SQL query.</summary>
<pre><code> ```sql
SELECT "issues".* SELECT "issues".*
FROM FROM
(WITH RECURSIVE "array_cte" AS MATERIALIZED (WITH RECURSIVE "array_cte" AS MATERIALIZED
...@@ -586,9 +584,7 @@ FROM ...@@ -586,9 +584,7 @@ FROM
FROM "recursive_keyset_cte" AS "issues" FROM "recursive_keyset_cte" AS "issues"
WHERE (COUNT <> 0)) issues WHERE (COUNT <> 0)) issues
LIMIT 20 LIMIT 20
</code> ```
</pre>
</details>
NOTE: NOTE:
To make the query efficient, the following columns need to be covered with an index: `project_id`, `issue_type`, `created_at`, and `id`. To make the query efficient, the following columns need to be covered with an index: `project_id`, `issue_type`, `created_at`, and `id`.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment