Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Feature] Bypass manifest lists on exact snapshot live-entry cache hits

オープン
#375 コメント 0 件 リアクション 0 件 担当者 1 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
cpp
領域
databases

調査の方向性

Start with AppendOnlyFileStoreScanTest.TestSnapshotLiveManifestCachePath and the public orc/append_09.db/append_09 fixture, using snapshot 5 and bucket 0 to reproduce the cache-hit path. Review draft implementation #374 and its focused regression tests for manifest-cache access counts, changed predicates, eviction/rebuild, and retained file counts. Done means eligible exact hits skip manifest reads and decoding while misses rebuild completely and filters, snapshot identity, and metrics remain correct.

索引モデルが issue の本文から書いたものです。

説明

Search before asking
  • I searched existing issues and found no report of this exact-hit planning overhead.
Motivation

Repeated scans of the same snapshot and bucket still read and decode the manifest lists before checking the snapshot live-manifest-entry cache. The cached live entries already contain the state needed for that bucket, so this work adds avoidable CPU and metadata access to repeated point-read planning.

To reproduce, use the public orc/append_09.db/append_09 test fixture with snapshot 5 and bucket 0, enable the snapshot live-manifest-entry cache, and reuse one cache across two scans. Instrument the MANIFEST cache accesses, as in AppendOnlyFileStoreScanTest.TestSnapshotLiveManifestCachePath. Before the proposed change, the second scan revisits the manifest-list path even though its exact snapshot/bucket live-entry lookup hits.

Expected: an eligible exact hit bypasses manifest-list reads and decoding, while each request still applies its own filters. A miss must rebuild the complete bucket. Snapshot selection and the existing snapshot-identity validation must remain intact.

Solution

Resolve the snapshot first and consult the existing snapshot live-entry cache before reading manifest lists. Retain the table file count in the transient cached payload so skipped-file metrics remain correct; report zero scanned manifests for an exact hit. Version the transient payload so incompatible entries fall back to rebuilding.

Draft implementation: #374. Regression tests check the manifest-cache access count, changed predicates, eviction/rebuild, and retained file counts. This change does not introduce a filesystem block cache or alter the persisted table format.

Anything else?

The identical patch passed 88 focused tests in a downstream C++17 Release build. Upstream CI for the draft still requires maintainer approval; no standalone end-to-end performance uplift is claimed for this individual optimization.

Are you willing to submit a PR?
  • I am willing to submit a PR; #374 is available as a draft.
主要言語
C++
スター
65
フォーク
29
平均マージ
2日 4時間
マージ済み PR(30日)
78

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/paimon-cpp のほかの issue

apache/paimon-cpp の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。