Qualify higher candidate, prefix-expansion and payload capacity profiles

Abierto
#66 0 comentarios 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
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
node.js, rust

Línea de trabajo

Start with the assessed fulltext source at commit a162f80890cd7516ba8e4fd21a7d329531ac58d0 and compare its candidate, prefix, payload, frame, and trace limits. Identify concrete workloads that exceed them, then measure correlated memory, CPU, queue, ranking, and response effects across the acceptance criteria. Done means documenting evidence for bounded higher profiles or explaining why current defaults should remain, including compatibility and allocation checks for any proposed increase.

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

Descripción

Outcome

Determine which fixed capacity limits need supported higher profiles and how those profiles remain bounded. Do not raise every ceiling or make caller input override operator policy.

Current constraints

The assessed fulltext source bounds candidates at 1,024 IDs / 1 MiB combined bytes, exact-prefix expansion at 50 dictionary terms per selected field, IDs/versions at 4,096 bytes each, source values at 1 MiB, and search request/response frames at 8 MiB. Trace requests have separate record/source/span bounds and an incompleteness signal. These limits interact; a higher item count alone may not increase usable capacity. No newly observed customer requirement is claimed.

Acceptance criteria

  • Identify concrete supported workloads that exceed existing limits; report units, failure behavior, memory/CPU/queue effects and correlated ceilings before proposing a profile.
  • Compare native structured filtering with larger candidate sets; preserve global ranking and totals rather than treating independent top-k batches as equivalent.
  • Qualify common-prefix vocabulary growth and any alternative expansion mechanism without silently truncating terms or changing ranking. Keep fuzzy scorer-construction costs distinct from the exact-prefix expansion guard.
  • Assess encoded-key growth, document partitioning semantics, response-byte-aware pages and trace batching/incompleteness. Any larger profile needs allocation/admission checks before expensive work and consistent capability metadata.
  • Keep existing defaults. Require explicit compatibility/rebuild policy if index identity, analyzers or wire formats change. Document when no increase is justified.

Parent: Epic: Extend fulltext search capabilities beyond the initial wrapper API. Term/clause configuration remains in Make query term and clause limits configurable with bounded resource policy; analyzer and matching changes remain in Support versioned per-field analyzers and additional languages and Make fuzzy edit distance and transpositions configurable. This is deferred qualification, not a prerequisite for Add bounded deep-result traversal and qualify autocomplete limits.

Priority: P3; uncommitted capacity investigation without an established blocked workload. Effort: High; multiple boundary and resource profiles require measurement/design. No milestone, customer-specific context or security incident.

Comment generated by kAIle (GPT-6)

Lenguaje dominante
Rust
Estrellas
3
Forks
0
Merge medio
15 h 12 min
PR fusionados (30 d)
11

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 HarperFast/fulltext

Todos los issues de HarperFast/fulltext

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.