Partitioning spike: Investigate impact on search when partitionining issues (#201871) · Issues · GitLab.org / GitLab · GitLab (original) (raw)

Skip to content

• • Why GitLab
  • Pricing
  • Contact Sales
  • Explore
• Why GitLab
• Pricing
• Contact Sales
• Explore
• Sign in
• Get free trial

Partitioning spike: Investigate impact on search when partitionining issues

In order to quantify the impact of partitioning better, we use issues and issue search as an example. In this spike, we build an environment with production data and compare issue search performance with and without partitioning.

Examples for the type of search that is problematic today can be found in #32791 (comment 282113625).

This issue likely entails the following steps:

• Prepare a production-like environment and upgrade the database to PG11 (a ZFS based clone would be useful here)
• Scripting to transform issues into a partitioned table
• Run a few query examples on the non-partitioned and partitioned issuestable (one example is here: #32791 (comment 282113625)) and compare
• Summarize findings

Examples to look at:

1. Index creation time
2. Index sizes
3. Query runtimes
4. Difference in planning times
5. Vacuum timings
6. Duration of index scan and index-only scan for partitioned/non-partitioned case

Edited Mar 10, 2020 by Andreas Brandl