[core] Support partition predicate pushdown for PartitionsTable#7628
Open
sundapeng wants to merge 3 commits intoapache:masterfrom
Open
[core] Support partition predicate pushdown for PartitionsTable#7628sundapeng wants to merge 3 commits intoapache:masterfrom
sundapeng wants to merge 3 commits intoapache:masterfrom
Conversation
PartitionsTable.withFilter() was a no-op (TODO), causing full manifest scans when querying with partition filters. This adds predicate pushdown following the same pattern as BucketsTable (apache#7592) and FilesTable (apache#7376). Key changes: - PartitionsScan extracts partition predicate via LeafPredicateExtractor - PartitionsSplit carries the predicate to PartitionsRead - Catalog path: in-memory filter preserving metadata columns - TableScan path: manifest-level pushdown via withPartitionFilter - PartitionPredicateHelper refactored to build+apply two-step pattern - parsePartitionSpec extended for key=value/key=value format Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…redicate filterByPredicate used raw p.spec().get(key) which renders null as literal "null", while toRow substitutes null with defaultPartitionName. This caused predicate pushdown to fail matching null-valued partitions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
testPartitionPredicateFilterMultiColumnKeys created MultiPartTable directly via filesystem (SchemaUtils.forceCommit), which works for local catalog but fails for REST catalog since it's unaware of tables created outside its API. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| Object value = | ||
| TypeUtils.castFromString( | ||
| partSpec.get(partitionKeys.get(i)), partitionType.getTypeAt(i)); | ||
| predicates.add(partBuilder.equal(i, value)); |
Contributor
There was a problem hiding this comment.
We should consider default partitions here. If the value is the default partition name, this should become isNull(...) rather than equal(...).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
PartitionsTable.withFilter()was a no-op (// TODOat line 189), causing full manifest scans when querying with partition filters likeSELECT * FROM t$partitions WHERE partition = 'dt=20260410'. This adds partition predicate pushdown following the same pattern established by BucketsTable (#7592), FilesTable (#7376), ManifestsTable (#7310), and ConsumersTable (#7329).The implementation uses a dual-path filtering strategy:
catalog.listPartitions()call and filters results in memory, keeping metadata columns (created_at,created_by,updated_by,options) intactInnerTableScan.withPartitionFilter()for manifest-level pruningAlso refactors
PartitionPredicateHelper.applyPartitionFilter()into a two-step build+apply pattern (buildPartitionPredicate()+ apply), and extendsparsePartitionSpec()to support PartitionsTable'skey=value/key=valueformat in addition to the existing{value1, value2}format.Tests
BucketsTableTestpasses (verifies refactored helper is backward-compatible)API and Format
No API or storage format changes.
Documentation
No documentation changes needed.