Skip to content

perf(scan): backport #10042 and #9614 (per-fragment scan overhead) - #93

Open
zehiko wants to merge 2 commits into
release-10.0.0from
zeljko/scan-per-fragment-overhead
Open

zehiko wants to merge 2 commits into
release-10.0.0from
zeljko/scan-per-fragment-overhead

Conversation

@zehiko

@zehiko zehiko commented Oct 23, 2026 •

Copy link
Copy Markdown
Member

Related

What

Two upstream changes, one commit each.

  1. perf(scan): share one planned filter across all fragments of a scan (perf(scan): share one planned filter across all fragments of a scan lance-format/lance#10042).
    read_fragment used to build a Planner and re-derive the read projection for every fragment.
    Now plan_to_scoped_fragments plans the read projection and physical filter once per distinct filter, and every fragment reuses them.
    The upstream commit does not apply cleanly here, because it builds on perf: share one ScanScheduler per base within a scan lance-format/lance#9417 (base_schedulers) and the blob-materialization context, which this branch doesn't have.
    This commit carries the same change adapted to release-10.0.0, including both upstream tests.
  2. perf(datafusion): stop cloning the session state for every execution (perf(datafusion): stop cloning the session state for every execution lance-format/lance#9614).
    LanceContextProvider keeps the cached SessionContext instead of cloning SessionState, so Planner::new no longer copies DataFusion's function registry.
    The utils.rs part of the upstream change depends on SharedPreFilterExec, which this branch doesn't have, and is left out.

Expected wins

Filtered scans over many small fragments should use about 20–25% less CPU per scan.
The saving comes from fixed work that used to be repeated for every fragment.
Scans dominated by decoding large fragments see little change.

Measured on a small filtered scan (4-column projection, a layer = … AND segment_id IN (…) filter, release build, 6 cores):

fragments scanned before after
8 6.9 ms CPU 5.4 ms (−23%)
32 21.9 ms 16.7 ms (−24%)
128 81.2 ms 61.9 ms (−24%)

For the dataplatform writer, these scans are 30–40% of its CPU during incremental registration, so the expected saving there is roughly 7–10% of writer CPU.

Testing

Compatibility

No API, format or behavioural change.
Both commits drop out when moving to a Lance release that contains lance-format#10042 and lance-format#9614 (v14.0.0 pre-releases onward).

Agent

🤖 This PR was opened by a coding agent (Claude Opus 5.5).

Hand-port of lance-format#10042 (b1a2a81) onto release-10.0.0.
Each distinct filter's read projection and physical filter are planned once in
plan_to_scoped_fragments and shared by Arc across fragments, instead of a
Planner::new + create_physical_expr + projection union per fragment.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@github-actions

Copy link
Copy Markdown

ACTION NEEDED
Lance follows the Conventional Commits specification for release automation.

The PR title and description are used as the merge commit message. Please update your PR title and description to match the specification.

For details on the error please inspect the "PR Title Check" action.

@zehiko
zehiko force-pushed the zeljko/scan-per-fragment-overhead branch from f49d1ff to 42853b1 Compare October 23, 2026 12:18
@zehiko zehiko changed the title perf(scan): cut per-fragment overhead in filtered scans (backport #10042, #9614 + per-scan open cache) perf(scan): backport #10042 and #9614 (per-fragment scan overhead) Oct 23, 2026
@zehiko zehiko added the upstream backport Already upstream, on a release later than ours label Oct 23, 2026
Cherry-pick of lance-format#9614 (2c4934c), exec.rs and planner.rs only;
the utils.rs doc note and regression test depend on SharedPreFilterExec, which
release-10.0.0 does not have.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@zehiko
zehiko force-pushed the zeljko/scan-per-fragment-overhead branch from 42853b1 to faeaace Compare October 23, 2026 12:34
@zehiko zehiko added the lance fork 10.0.0 Landed on the release-10.0.0 fork line label Oct 23, 2026

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-deps A-encoding lance fork 10.0.0 Landed on the release-10.0.0 fork line performance upstream backport Already upstream, on a release later than ours

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants