incremental query file and partition pruning #2
Conversation
This file contains 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
psendyk
force-pushed
the
pawel/incremental-query-pruning
branch
2 times, most recently
from
0c11544 to
9c4dd0f
Compare
psendyk
force-pushed
the
pawel/incremental-query-pruning
branch
from
9c4dd0f to
99c76dc
Compare
ramsgoli
approved these changes
Sep 18, 2023
ramsgoli
reviewed
Sep 18, 2023
| @@ -102,13 +102,14 @@ case class MergeOnReadIncrementalRelation(override val sqlContext: SQLContext, | |||
| val fsView = new HoodieTableFileSystemView(metaClient, timeline, affectedFilesInCommits) | |||
|
|
|||
| val modifiedPartitions = getWritePartitionPaths(commitsMetadata) | |||
| val globMatcher = new GlobPattern("*" + globPartitionPattern) | |||
There was a problem hiding this comment.
Might auto-prefixing the glob with an * result in potentially weird behavior?
There was a problem hiding this comment.
What do you mean by weird? Honestly didn't think about it much, just kept it consistent with the existing logic at
.
psendyk
added a commit
that referenced
this pull request
Apr 10, 2024
psendyk
pushed a commit
that referenced
this pull request
Apr 10, 2024
…ernalWriterHelper::write(...) (apache#10272) Issue: There are two configs which when set in a certain manner throws exceptions or asserts 1. Configs to disable populating metadata fields (for each row) 2. Configs to drop partition columns (to save storage space) from a row With #1 and #2, partition paths cannot be deduced using partition columns (as the partition columns are dropped higher up the stack. BulkInsertDataInternalWriterHelper::write(...) relied on metadata fields to extract partition path in such cases. But with #1 it is not possible resulting in asserts/exceptions. The fix is to push down the dropping of partition columns down the stack after partition path is computed. The fix manipulates the raw 'InternalRow' row structure by only copying the relevent fields into a new 'InternalRow' structure. Each row is processed individually to drop the partition columns and copy it a to new 'InternalRow' Co-authored-by: Vinaykumar Bhat <vinay@onehouse.ai>
psendyk
pushed a commit
that referenced
this pull request
Apr 10, 2024
There are a couple of issues in how functional indexes are managed. 1. HoodieSparkFunctionalIndexClient::create(...) was failing a register a functional index iff a (different) functional index was already created. Fixed this check by looking up the index-name in the FunctionalIndexMetadata 2. HoodieTableConfig `TABLE_METADATA_PARTITIONS` and `TABLE_METADATA_PARTITIONS_INFLIGHT` should actually store the Metadata partition path. While the path is contained in the `MeatadatPartitionType` for most of the indexes, it is not correct for functional-index. MeatadatPartitionType.FUNCTIONAL_INDEX only stores the prefix (i.e func_index_). The actual partition path needs to be extracted from the index-name. 3. Because of #2, most of the helper methods that operate on metadata-partitions, should take partition-path (and not partition-type) This PR addresses the problem listed above. This fix is required to add SQL support for secondary-indexes (the configs for which will be based on functional-index-config). Note that there are still issues with some functional-index operations (like drop index / delete partition) because of the issues listed here. Those will be fixed in a subsequent PR. Co-authored-by: Vinaykumar Bhat <vinay@onehouse.ai>
psendyk
pushed a commit
that referenced
this pull request
Apr 10, 2024
…ernalWriterHelper::write(...) (apache#10272) Issue: There are two configs which when set in a certain manner throws exceptions or asserts 1. Configs to disable populating metadata fields (for each row) 2. Configs to drop partition columns (to save storage space) from a row With #1 and #2, partition paths cannot be deduced using partition columns (as the partition columns are dropped higher up the stack. BulkInsertDataInternalWriterHelper::write(...) relied on metadata fields to extract partition path in such cases. But with #1 it is not possible resulting in asserts/exceptions. The fix is to push down the dropping of partition columns down the stack after partition path is computed. The fix manipulates the raw 'InternalRow' row structure by only copying the relevent fields into a new 'InternalRow' structure. Each row is processed individually to drop the partition columns and copy it a to new 'InternalRow' Co-authored-by: Vinaykumar Bhat <vinay@onehouse.ai>
psendyk
added a commit
that referenced
this pull request
Apr 11, 2024
psendyk
added a commit
that referenced
this pull request
Apr 12, 2024
ramsgoli
pushed a commit
that referenced
this pull request
Nov 4, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Makes the MOR table incremental queries faster via following optimizations:
hoodie.datasource.read.incr.path.globmatchhoodie.datasource.read.incr.partition.glob