diff options
Diffstat (limited to 'doc/development/database/pagination_guidelines.md')
| -rw-r--r-- | doc/development/database/pagination_guidelines.md | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/doc/development/database/pagination_guidelines.md b/doc/development/database/pagination_guidelines.md index fe2e3b46939..54b315b9dd9 100644 --- a/doc/development/database/pagination_guidelines.md +++ b/doc/development/database/pagination_guidelines.md @@ -1,7 +1,7 @@ --- stage: Data Stores 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/#assignments +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- # Pagination guidelines @@ -50,9 +50,9 @@ When we list records on the page we often provide additional filters and differe For the MVC version, consider the following: - Reduce the number of sort options to the minimum. -- Reduce the number of filters (dropdown, search bar) to the minimum. +- Reduce the number of filters (dropdown list, search bar) to the minimum. -To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Note that indexes are not free, they can significantly affect the `UPDATE` query timings. +To make sorting and pagination efficient, for each sort option we need at least two database indexes (ascending, descending order). If we add filter options (by state or by author), we might need more indexes to maintain good performance. Indexes are not free, they can significantly affect the `UPDATE` query timings. It's not possible to make all filter and sort combinations performant, so we should try optimizing the performance by usage patterns. @@ -154,7 +154,7 @@ Here we're leveraging the ordered property of the b-tree database index. Values ##### `COUNT(*)` on a large dataset -Kaminari by default executes a count query to determine the number of pages for rendering the page links. Count queries can be quite expensive for a large table. In an unfortunate scenario the queries simply time out. +Kaminari by default executes a count query to determine the number of pages for rendering the page links. Count queries can be quite expensive for a large table. In an unfortunate scenario the queries time out. To work around this, we can run Kaminari without invoking the count SQL query. @@ -264,7 +264,7 @@ Looking at the query execution plan, we can see that this query read only 5 rows ##### No page numbers -Offset pagination provides an easy way to request a specific page. We can simply edit the URL and modify the `page=` URL parameter. Keyset pagination cannot provide page numbers because the paging logic might depend on different columns. +Offset pagination provides an easy way to request a specific page. We can edit the URL and modify the `page=` URL parameter. Keyset pagination cannot provide page numbers because the paging logic might depend on different columns. In the previous example, the column is the `id`, so we might see something like this in the `URL`: |