Skip to content

fix(optimizer): Resolve bucketing per scan, not per table (#1812) - #1812

Open
pradeepvaka wants to merge 1 commit into
facebookincubator:mainfrom
pradeepvaka:export-D115056959
Open

fix(optimizer): Resolve bucketing per scan, not per table (#1812)#1812
pradeepvaka wants to merge 1 commit into
facebookincubator:mainfrom
pradeepvaka:export-D115056959

Conversation

@pradeepvaka

@pradeepvaka pradeepvaka commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294

Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table’s current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector’s guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Partition selection records planning wall time, CPU time, and selected-partition count separately from runtime fallback listing. Axel publishes both paths through the existing partition-resolution time-series counter.

Differential Revision: D115056959

@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Meta Open Source bot. label Sep 1, 2026
@meta-codesync meta-codesync Bot changed the title fix(optimizer): Resolve bucketing per scan, not per table fix(optimizer): Resolve bucketing per scan, not per table (#1812) Sep 1, 2026
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:

Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
@pradeepvaka
pradeepvaka force-pushed the export-D115056959 branch 2 times, most recently from 9f95d6a to 2cc60d2 Compare September 1, 2026 06:21
@meta-codesync meta-codesync Bot changed the title fix(optimizer): Resolve bucketing per scan, not per table (#1812) fix(optimizer): Resolve bucketing per scan, not per table Sep 1, 2026
@meta-codesync

meta-codesync Bot commented Sep 1, 2026

Copy link
Copy Markdown

@pradeepvaka has exported this pull request. If you are a Meta employee, you can view the originating Diff in D115056959.

@meta-codesync meta-codesync Bot changed the title fix(optimizer): Resolve bucketing per scan, not per table fix(optimizer): Resolve bucketing per scan, not per table (#1812) Sep 1, 2026
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
@meta-codesync meta-codesync Bot changed the title fix(optimizer): Resolve bucketing per scan, not per table (#1812) fix(optimizer): Resolve bucketing per scan, not per table Sep 1, 2026
@pradeepvaka
pradeepvaka force-pushed the export-D115056959 branch 2 times, most recently from 8caeacb to d1c7549 Compare September 1, 2026 07:57
@meta-codesync meta-codesync Bot changed the title fix(optimizer): Resolve bucketing per scan, not per table fix(optimizer): Resolve bucketing per scan, not per table (#1812) Sep 1, 2026
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
@pradeepvaka
pradeepvaka force-pushed the export-D115056959 branch 2 times, most recently from 25304f7 to 9ae0f5e Compare September 1, 2026 14:49
pradeepvaka added a commit to pradeepvaka/verax that referenced this pull request Sep 1, 2026
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table's current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector's guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Differential Revision: D115056959
…cubator#1812)

Summary:
X-link: https://github.com/facebookincubator/axel/pull/294


Tables can be rebucketed without rewriting older partitions. A filtered scan may therefore read partitions that do not match the table’s current bucketing, even though planning treated the layout as a guarantee.

After connector filters are pushed, the optimizer asks for the exact selected partitions and their storage bucketing. The scan keeps that result, and distribution planning uses the connector’s guarantee instead of assuming the table definition describes every selected partition.

Connectors that only participate in planning can continue to use their declared layout without registering execution metadata. Connectors that support partition selection reuse the same result for estimates and final scan emission, so planning decisions stay aligned.

Partition selection records planning wall time, CPU time, and selected-partition count separately from runtime fallback listing. Axel publishes both paths through the existing partition-resolution time-series counter.

Differential Revision: D115056959
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Meta Open Source bot. meta-exported

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant