perf(Audit): Audit log pagination is expensive

オープン
#8,856 コメント 2 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
postgresql, python

調査の方向性

Start by locating the audit log list endpoints and how they apply page-number pagination; inspect the count query and the indexes added for #8846. The issue identifies the expensive per-request count as the problem, but does not specify a replacement pagination approach. Done should reduce the cost of listing audit logs on large projects while preserving the endpoint behavior.

索引モデルが issue の本文から書いたものです。

説明

Problem

The audit log list endpoints use page-number pagination, which runs SELECT COUNT(*) on every request to work out the total and the last page. The count reads every audit log row that matches the filters, so its cost grows with the size of the project's audit log, even when the client only asks for the first page.

On large projects, the count can take up to 500 ms. Indexes added for #8846 make this cheaper, but it's still a lot

主要言語
Python
スター
7.1k
フォーク
603
平均マージ
3日 8時間
マージ済み PR(30日)
102

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Flagsmith/flagsmith のほかの issue

Flagsmith/flagsmith の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。