Export partition - allow non matching partition expressions in case we can prove the destination expression does not split the data - #2074
Conversation
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3f3af7c4fc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
Consider mentioning 'export' in the title and/or description |
Done, I'll soon add the description |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ca43cf1f6d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
I think this deserves a separate issue |
Export partition is already experimental and back by a setting the user must opt in |
|
@Selfeer I would appreciate if you could "humanize" a bit more those AI reports. For example, the following issue is very hard to understand and doesn't explain what is happening: 1. 🔴 High — Argument order lost, monotonicity proof evaluates the wrong expression. It says "anchor" pointing to some code location. Then it says the impact. Then the trigger. It is too much to read to understand the real problem. Brain energy required to process this is very high. Instead, if you could understand the issue yourself first and then give me a few SQL instructions that repro the case and a human explanation of what's going on, that would be 100 times better. |
I agree. I'd much rather do it the way you described: perform my own investigation on the findings and raise issues as needed-and we actually do that. But even in that case, I would still have to post this exact message first. The purpose of the audit review has always been to perform a quick review of the PR without running any tests first, share the findings with the developer, and let you decide whether they are actual issues. If they are, we then raise separate issues afterward. I can update the skills we use for the audit review to make the output easier to read, but overall, the audit review has always been a separate part of the verification process, separate from our actual testing. |
|
@k-morozov hi, I have made some refactorings, fixed conflicts and updated the docs. Could you please re-review it? |
|
@Selfeer regarding the 5 AI findings you posted
|
| "To allow its usage, enable the setting `allow_insert_into_iceberg`."); | ||
| } | ||
|
|
||
| ExportPartitionUtils::verifyExportSchemaCastable( |
There was a problem hiding this comment.
Calls ExportPartitionUtils::verifyExportSchemaCastable twice here and below.
There was a problem hiding this comment.
Thanks, bad rebase
| ) | ||
|
|
||
|
|
||
| def test_export_part_unnamed_tuple_partition_key_owner_matching_named_destination_is_allowed(cluster): |
| /// so the same expression over the two types can produce different partitions. | ||
| bool isSameTypeForPartitioning(const DataTypePtr & lhs, const DataTypePtr & rhs) | ||
| { | ||
| return lhs->getName() == rhs->getName(); |
There was a problem hiding this comment.
What about unnamed Tuple, Array, etc?
Does it related with test test_export_part_unnamed_tuple_partition_key_owner_matching_named_destination_is_allowed that was removed?
up: maybe haveSameTupleElementLayout will be usefull.
There was a problem hiding this comment.
Answering #2074 (comment) here as it relates to this question.
The main reason I removed that test, and yes, it is affected by this name check, is to draw a line of "good enough" and move on. This PR needs to get merged so that we fix the broader and more common use cases, we can worry about named tuples later.
|
|
||
| /// A NULL value forms its own destination partition, so a Nullable column may split the source | ||
| /// partition; min/max cannot rule that out. Require a structural match for such columns. | ||
| if (isNullableOrLowCardinalityNullable(source_type)) |
There was a problem hiding this comment.
Seems that this behauvor should be in documentation (and motivation maybe?) Also I need to find tests for this condition..
|
|
||
| /// Compute the global min/max index of the parts | ||
| IMergeTreeDataPart::MinMaxIndex minmax; | ||
| for (const auto & part : parts) |
There was a problem hiding this comment.
As I can see, we prepare mimax every time even if we have an equal partition key. But we really need it only for verifyOutputMapsToSinglePartition.
There was a problem hiding this comment.
Right, but verifyOutputMapsToSinglePartition is called within a for loop. What is your suggestion?
There was a problem hiding this comment.
For example, create 2 loops:
1 for happy path.
2. for verifyOutputMapsToSinglePartition.
So we could create minmax between 1 and 2 steps.
Another way - to fill minmax within the current loop only once before verifyOutputMapsToSinglePartition.
There was a problem hiding this comment.
Imo, that's somewhat of an unecessary "optimization" that will not give us any speed up with the cost of more code. I vote for keeping it as is unless you strongly object.
| if (parquet_row_group_size_bytes) | ||
| json.set("parquet_row_group_size_bytes", *parquet_row_group_size_bytes); | ||
| if (iceberg_partition_timezone) | ||
| json.set("iceberg_partition_timezone", *iceberg_partition_timezone); |
There was a problem hiding this comment.
We try to set this setting for export. But if we have several columns with different timezones, we would set the value from the setting for all of them, right?
There was a problem hiding this comment.
I think that's how this setting was designed, @ianton-ru can confirm. AFAIK, this setting was created due to a misconception on the Apache Iceberg specs (the spec itself is poorly written) when it was believed we could tweak the timezone of an apache iceberg column. When in reality, according to 3rd party docs, the types are always UTC.
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Allow export partition through different partition expressions as long as the destination expression does not repartition the data. This is validated at schedule time through two mechanisms:
Documentation entry for user-facing changes
...
CI/CD Options
Exclude tests:
Regression jobs to run: