Query DB: measure repeated legacy-owner key parsing
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 22/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- typescript
- Ambito
- data-engineering
Direzione di ricerca
Start in packages/query-db-collection/src/query.ts at getLegacyOwnerHashes, where candidates are built from persisted owner hashes and retention markers and JSON-parsed per eligible equality demand. Write a benchmark that varies owner count, demand count and marker count to measure parsing cost. Done means a measured result showing whether an index built once per metadata generation is worth it, with the static-key prefix and markerless-owner migration checks still passing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Observation
PR #2134 performs one persisted-row metadata scan per sync run, but getLegacyOwnerHashes then builds a candidate set from every persisted owner hash and every retention marker and JSON-parses candidates for each eligible equality demand (packages/query-db-collection/src/query.ts). This gives repeated work proportional to demands × (owners + markers), including fresh installs with no historical alias. The current oracle bounds scan count but not this parsing work.
This is a source-level performance concern; no user latency regression has been measured. Keep the correctness repair in #2134 focused.
Follow-up
Measure load cost across increasing owner and demand counts, including marker-heavy storage. If material, build the normalized historical-key index once per relevant metadata generation, with explicit updates when owners or markers change. Preserve the current static-key prefix and full-demand checks and the markerless-owner migration witness.
- Lingua principale
- TypeScript
- Stelle
- 4k
- Fork
- 277
- Merge medio
- 17h 40m
- PR unite (30g)
- 223
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di TanStack/db
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Garbage collection cleans up a collection while one of its transactions is still persistingForse già presa @Nabil372 l’ha presa 2 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
persistedCollectionOptions without a schema can't be passed to createCollection (follow-up to #1452)Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
awslabs/visual-asset-management-system#804 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
restatedev/sdk-typescript#813 ·
-
bug desktop P1 session XS
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
Merit-Systems/x402scan#1312 ·
-
type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
Azure/apiops-cli#331 ·
I maintainer di solito rispondono entro 3 giorni