Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

alternate approaches to warning about "millions of sequential scans"

Abierto
  • ¿Algo no está bien?
#1,208 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
18/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
databases
Área
observability

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!

Lenguaje dominante
JavaScript
Estrellas
133
Forks
67
Merge medio
22 h 55 min
PR fusionados (30 d)
53

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de nextcloud/serverinfo

Todos los issues de nextcloud/serverinfo

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.