Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
206009a2
Commit
206009a2
authored
Oct 18, 2021
by
Evan Read
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Switch from inline HTML to Markdown for code in topic
Fixes compatibility problems with markdownlint-cli 0.29.0
parent
8f114bde
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
12 additions
and
16 deletions
+12
-16
doc/development/database/efficient_in_operator_queries.md
doc/development/database/efficient_in_operator_queries.md
+12
-16
No files found.
doc/development/database/efficient_in_operator_queries.md
View file @
206009a2
...
...
@@ -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
the end-user. For large groups, this final step requires both large memory and CPU resources.
<details>
<summary>
Expand this sentence to see the execution plan for this DB query.
</summary>
<pre><code>
Execution plan for this DB query:
```
sql
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
I
/
O
Timings
:
read
=
336
.
879
...
...
@@ -106,8 +106,7 @@ The execution of the query can be largely broken down into three steps:
Planning
Time
:
7
.
750
ms
Execution
Time
:
967
.
973
ms
(
36
rows
)
</code></pre>
</details>
```
The performance of the query depends on the number of rows in the database.
On average, we can say the following:
...
...
@@ -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
)
```
<details>
<summary>
Expand this sentence to see the SQL query.
</summary>
<pre><code>
The SQL query:
```
sql
SELECT
"issues"
.
*
FROM
(
WITH
RECURSIVE
"array_cte"
AS
MATERIALIZED
...
...
@@ -353,8 +352,7 @@ SELECT (records).*
FROM
"recursive_keyset_cte"
AS
"issues"
WHERE
(
COUNT
<>
0
))
issues
-- filtering out the initializer row
LIMIT
20
</code></pre>
</details>
```
### Using the `IN` query optimization
...
...
@@ -466,9 +464,9 @@ Gitlab::Pagination::Keyset::InOperatorOptimization::QueryBuilder.new(
).
execute
.
limit
(
20
)
```
<details>
<summary>
Expand this sentence to see the SQL query.
</summary>
<pre><code>
The SQL query:
```
sql
SELECT
"issues"
.
*
FROM
(
WITH
RECURSIVE
"array_cte"
AS
MATERIALIZED
...
...
@@ -586,9 +584,7 @@ FROM
FROM
"recursive_keyset_cte"
AS
"issues"
WHERE
(
COUNT
<>
0
))
issues
LIMIT
20
</code>
</pre>
</details>
```
NOTE:
To make the query efficient, the following columns need to be covered with an index:
`project_id`
,
`issue_type`
,
`created_at`
, and
`id`
.
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment