Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #2923

Closed (moved)
(moved)
Open
Created Apr 15, 2011 by Karsten Loesing@karsten

Improve materialized views in the metrics database

The metrics database schema uses periodically updated tables similar to materialized views for aggregating statistics. When inserting data into the database, we write the dates that have changed to a separate updates table. Every three hours, we delete the aggregates for these days and recompute them, which takes a few minutes.

The recompute step that takes most of the time is refresh_user_stats(), which is no surprise given the complexity of that function. We should try to simplify this function, possibly by pre-computing partial results that can be reused for other statistics. Ideally, recomputing aggregates should run in under one minute, given that we want to add more materialized views for more aggregate statistics in the future. In particular, I'd like to know which particular SQL parts slow us down in order to avoid them in the future.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking