Persist the CUDA join table across probe batches and size group tables by distinct keys

Aperta
  • Qualcosa non va?
#45 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
databases, performance

Direzione di ricerca

Start with crates/oxidelake-device/src/cuda/ops.rs:392-409 and crates/oxidelake-compute/src/operator.rs:422-443 to trace join table construction and build-column upload, then inspect the aggregate paths at ops.rs:540-544 and ops.rs:773. Implementing reuse, distinct-key sizing, and occupied-slot readback spans device and compute code; done means the on-demand GPU job records before and after timings for the conformance join and 10M-row GROUP BY k with 100 keys, with aggregate bytes_d2h proportional to groups.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Today — crates/oxidelake-device/src/cuda/ops.rs:392-409 allocates and builds the device hash table (capacity = 2 × right.num_rows, oxide_hj_build) inside hash_join, i.e. once per probe batch, although device_build (crates/oxidelake-compute/src/operator.rs:422-443) already uploads the build columns once. The aggregate sizes its group table by input rows (ops.rs:773, capacity = 2 × input.num_rows) and reads back cap entries every call (:540-544); with the whole-input aggregate a 10M-row GROUP BY allocates 2²⁵ slots × 12 B plus cap × 8 B per aggregate and copies it all back.

Why it is worth fixing — join cost on device is O(probe batches × build rows) and aggregate transfer is O(rows) regardless of cardinality; both are the audit's "P1 (rest)" and they dominate once the aggregate streams.

Fix — GpuBackend::prepare_join_build returning an opaque device table reused across batches (dropped with the operator); size the group table from a distinct-key estimate (HyperLogLog on the host over the first batch, or a two-pass count) and read back only occupied slots.

Done when — the on-demand GPU job records before/after timings for the conformance join and a 10M-row GROUP BY k (100 keys); bytes_d2h for the aggregate is proportional to groups, not rows.

Lingua principale
Rust
Stelle
1
Fork
2
Merge medio
1g 11h
PR unite (30g)
7

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di vyncint/oxidelake

Tutte le issue di vyncint/oxidelake

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.