Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

perf(query): narrow glob pruning, cache footprint and trace-candidate reads

Đang mở
#281 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
go

Hướng nghiên cứu

Start with internal/query/file_snapshot.go and the review threads linked from issue #281, then trace the read_trace_parts and read_trace_candidates paths described in the issue. Measure glob file reads, cache size and trace-read cost under the stated workloads before choosing an approach. Done means the four review follow-ups are addressed, parity coverage is added where requested, and the measured trade-offs are documented.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

PR #272 review follow-ups from the e818a8db review (https://github.com/labstack/fanout/pull/272#pullrequestreview-5385883605). None of these affect correctness. Each item below links its original thread.

  1. Captured-ID glob filter does not prune files (medium, measured): https://github.com/labstack/fanout/pull/272#discussion_r4160763194
    internal/query/file_snapshot.go filters the broad-selection glob with substr(filename, …) IN (ids). DuckDB's multi-file reader does not push that down, so every file matching the glob is opened and scanned. With 100 batches and 80 selected, profiles show 101 files read (explicit list: 80; filename IN ('<full path>', …): 81). This path also loses newest-first ordering for top-N reads. Options: filter on full paths, or raise the explicit-list threshold, and measure statement size against files read.

  2. Read-cache catalog is about as large as the Parquet data (medium-low, measured): https://github.com/labstack/fanout/pull/272#discussion_r4160763216
    After a 300 s run at 120k offered rows/s (telemetrygen, two spans per trace), catalog.duckdb was 762 MiB against 529 MiB of Parquet: about 474 MiB of used blocks and 288 MiB free. read_trace_parts and read_trace_candidates each held about 3.6M rows. Document that cache size scales with trace count and that free blocks are not returned without a rebuild, and consider compaction of the cache file.

  3. Trace candidates re-aggregate every overlapping part when any cached file straddles the window (low, plausible): https://github.com/labstack/fanout/pull/272#discussion_r4160763233
    Under continuous ingest the newest cached file usually straddles the window end, so most trace reads group read_trace_parts for all overlapping batches instead of reading read_trace_candidates. Restrict the parts aggregation to trace_id IN (partial) and take fully contained traces from the index, as the other branch does. Add a parity test and measure trace read cost as retention grows.

  4. The candidate index is evaluated twice in the contained-files branch (low): https://github.com/labstack/fanout/pull/272#discussion_r4160763241
    The branch added in e7dbc79a reads index once for the fully contained rows and again inside partial. On scoped reads with mixed-scope traces this repeats the read_trace_parts union. Results are unaffected. Bind it once, or share it with the rewrite in item 3.

Related: #277 (ingest CPU per row), #278 (sustained read capacity and peak RSS).

Ngôn ngữ chính
HTML
Star
6
Fork
0
Merge trung bình
2 giờ 25 phút
Pull request đã merge (30 ngày)
25

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của labstack/fanout

Tất cả issue của labstack/fanout

Issue tương tự

Thêm issue về Databases

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.