Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

alternate approaches to warning about "millions of sequential scans"

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

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
18/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
活発
技術スタック
databases
領域
observability

調査の方向性

The payload names no file or test, so start by finding where the "many sequential scans and no index scans" warning text is produced in the repository. The issue asks for a design decision first: whether to count scans over time, downgrade the warning to a note, or exempt specific tables. Done means maintainers agree on one approach in the thread, and only then is a change made.

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

説明

0. Needs triage enhancement

Upgraded from NC-34 to 35.0.1, now I see what is now a warning I cannot easily fix:

Some tables have many sequential scans and no index scans, suggesting a missing index.

2 table(s) have > 1M sequential scans without any index scans.

    oc_share
    oc_mimetypes

Some sleuthing suggests going into internal databases in order to squelch this, I think that's in general a bad idea.

Suggestions?

  1. Count sequential scans over time, not just overall. My instances of NC are many years old, counting the number of scans over that period is a naive metric.
  2. For those two tables (any others?), don't warn about it. Or call it a Note. But certainly not a Warning, otherwise I'll hit alarm-fatigue.

I've been using NC for years, but for newer users, less-tolerant users, and/or those who are less invested in NC in general, I suggest it isn't hard to imagine them migrating away due to untrusted warnings/alarms that cannot be easily dealt with.

I like warnings/alarms, I invest time periodically to assess the health of my servers. But alarm-fatigue is a real thing and I measure and value the admin time I need for each service. As it adds up, the "value" changes, and we are smart to reassess things. Please help improve the warning process, I don't think bullet 1 is onerous, and it'll go a long way to normalizing this type of problem (which can be quite real and impactful, I suspect).

Thanks!

主要言語
JavaScript
スター
133
フォーク
67
平均マージ
22時間 55分
マージ済み PR(30日)
53

環境構築

はじめの一歩

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

nextcloud/serverinfo のほかの issue

nextcloud/serverinfo の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

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

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