You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "fresh-borzoni (via GitHub)" <gi...@apache.org> on 2025/12/30 14:28:15 UTC

[PR] [FLINK-38753] Enrich upsert keys by equi-join equivalences [flink]

fresh-borzoni opened a new pull request, #27372:
URL: https://github.com/apache/flink/pull/27372

   ## What is the purpose of the change
   closes https://issues.apache.org/jira/browse/FLINK-38753
   Enriches upsert keys using equi-join column equivalences to avoid unnecessary `upsertMaterialize` in streaming sinks.
   
   Consider: `src1` pk `{a1}`, `src2` pk `{a2, b2}`, join on `a1 = a2`, sink pk `{a1, b2}`. 
   Currently the join produces upsert keys `{a2, b2}` and `{a1, a2, b2}` - neither contains `{a1, b2}`, 
   so Flink adds `upsertMaterialize`. But since `a1 = a2` in the join, `{a1, b2}` is semantically equivalent to `{a2, b2}`. 
   
   This PR makes the planner recognize that equivalence.
   
   ## Brief change log
   
   - Added `enrichJoinedKeys` to substitute columns via `JoinInfo` equivalences
   - Added `enrichMultiJoinKeys` for `MultiJoin` equivalences  
   - Added shared `enrichKeysWithEquivalences` core logic
   - Applied enrichment in `getUpsertKeys` for both `Join` and `MultiJoin`
   
   ## Verifying this change
   
   New tests added:
   
   - `testJoinUpsertKeyEnrichmentInnerJoinBasic` - basic case from FLINK-38753
   - `testJoinUpsertKeyEnrichmentInnerJoinReverse` - enrichment in opposite direction
   - `testJoinUpsertKeyEnrichmentLeftJoin` - left outer join
   - `testJoinUpsertKeyEnrichmentRightJoin` - right outer join
   - `testJoinUpsertKeyEnrichmentMultipleEquiConditions` - multiple equi-join columns
   - `testJoinUpsertKeyEnrichmentNegativeCase` - confirms `upsertMaterialize` when sink pk uses non-join column
   - `testUpsertKeyEnrichmentThreeWayJoin` - multi-way join via `MultiJoin`
   
   ## Does this pull request potentially affect one of the following parts:
   
   - Dependencies (does it add or upgrade a dependency): no
   - The public API, i.e., is any changed class annotated with `@Public(Evolving)`: no
   - The serializers: no
   - The runtime per-record code paths (performance sensitive): no
   - Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
   - The S3 file system connector: no
   
   ## Documentation
   
   - Does this pull request introduce a new feature? no
   - If yes, how is the feature documented? not applicable
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "xuyangzhong (via GitHub)" <gi...@apache.org>.
xuyangzhong commented on code in PR #27372:
URL: https://github.com/apache/flink/pull/27372#discussion_r3192916808


##########
flink-table/flink-table-planner/src/test/scala/org/apache/flink/table/planner/plan/stream/sql/join/JoinTest.scala:
##########
@@ -815,4 +815,303 @@ class JoinTest extends TableTestBase {
         "Key: 'table.exec.mini-batch.size' , default: -1 (fallback keys: []) must be > 0.")
       .isInstanceOf[IllegalArgumentException]
   }
+
+  // Tests for FLINK-38753: Enrich upsert keys by equiv expressions in joins

Review Comment:
   nit remove this comment



##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -44,6 +44,7 @@ import scala.collection.JavaConversions._
  * for the standard logical algebra.
  */
 class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
+  private val MaxGeneratedEnrichedKeys = 128

Review Comment:
   In fact, as long as a node contains a filter, the upsert key can be enriched through equivalence relations. However, the biggest issue is that this would lead to too many combinations of upsert keys. I imagine you've considered this problem as well, which is why you used `MaxGeneratedEnrichedKeys` here to prevent the upsert key from exploding.
   
   Perhaps we could take a different approach — introduce a new metadata, FlinkRelMdEquivalenceColumns, and then leverage the new equivalence column information at the places where upsert keys are consumed for optimization (See more about FlinkChangelogModeInferenceProgram#canUpsertKeysWithImmutableColsSatisfyPk). While this would add some complexity to the call sites that use upsert keys, it would not be subject to the limitation of upsert key explosion. What do you think?



##########
flink-table/flink-table-planner/src/test/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeysTest.scala:
##########
@@ -399,23 +399,23 @@ class FlinkRelMdUpsertKeysTest extends FlinkRelMdHandlerTestBase {
   @Test
   def testGetUpsertKeysOnJoin(): Unit = {
     assertEquals(
-      toBitSet(Array(1), Array(5), Array(1, 5), Array(5, 6), Array(1, 5, 6)),
+      toBitSet(Array(1), Array(5), Array(1, 5), Array(1, 6), Array(5, 6), Array(1, 5, 6)),
       mq.getUpsertKeys(logicalInnerJoinOnUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalInnerJoinNotOnUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalInnerJoinOnRHSUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalInnerJoinWithoutEquiCond).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalInnerJoinWithEquiAndNonEquiCond).toSet)
 
     assertEquals(
-      toBitSet(Array(1), Array(1, 5), Array(1, 5, 6)),
+      toBitSet(Array(1), Array(1, 5), Array(1, 6), Array(1, 5, 6)),
       mq.getUpsertKeys(logicalLeftJoinOnUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalLeftJoinNotOnUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalLeftJoinOnRHSUniqueKeys).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalLeftJoinWithoutEquiCond).toSet)
     assertEquals(toBitSet(), mq.getUpsertKeys(logicalLeftJoinWithEquiAndNonEquiCond).toSet)
 
     assertEquals(
-      toBitSet(Array(5), Array(1, 5), Array(5, 6), Array(1, 5, 6)),
+      toBitSet(Array(5), Array(5, 6), Array(1, 5), Array(1, 5, 6)),

Review Comment:
   revert this change



##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -359,19 +360,73 @@ class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
     val rightKeys = fmq.getUpsertKeys(right)
     val leftImmutableColumns = fmq.getImmutableColumns(left)
     val rightImmutableColumns = fmq.getImmutableColumns(right)
+    val leftFieldCount = left.getRowType.getFieldCount
 
-    FlinkRelMdUniqueKeys.INSTANCE.getJoinUniqueKeys(
+    val baseKeys = FlinkRelMdUniqueKeys.INSTANCE.getJoinUniqueKeys(
       joinRelType,
-      left.getRowType.getFieldCount,
-      // Retain only keys whose columns are contained in the join's equi-join columns

Review Comment:
   No need to remove these comments.



##########
flink-table/flink-table-planner/src/test/scala/org/apache/flink/table/planner/plan/stream/sql/join/JoinTest.scala:
##########
@@ -815,4 +815,303 @@ class JoinTest extends TableTestBase {
         "Key: 'table.exec.mini-batch.size' , default: -1 (fallback keys: []) must be > 0.")
       .isInstanceOf[IllegalArgumentException]
   }
+
+  // Tests for FLINK-38753: Enrich upsert keys by equiv expressions in joins
+  @Test
+  def testJoinUpsertKeyEnrichmentInnerJoinBasic(): Unit = {
+    // Basic case from FLINK-38753: src1 pk {a1}, src2 pk {a2, b2}, join a1 = a2

Review Comment:
   nit remove ``Basic case from FLINK-38753:



##########
flink-table/flink-table-planner/src/test/scala/org/apache/flink/table/planner/plan/stream/sql/join/JoinTest.scala:
##########
@@ -815,4 +815,303 @@ class JoinTest extends TableTestBase {
         "Key: 'table.exec.mini-batch.size' , default: -1 (fallback keys: []) must be > 0.")
       .isInstanceOf[IllegalArgumentException]
   }
+
+  // Tests for FLINK-38753: Enrich upsert keys by equiv expressions in joins
+  @Test
+  def testJoinUpsertKeyEnrichmentInnerJoinBasic(): Unit = {

Review Comment:
   nit extract the same logic from these new tests.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-5580466963

   This PR is being marked as stale since it has not had any activity in the last 90 days. 
   If you would like to keep this PR alive, please leave a comment asking for a review. 
   If the PR has merge conflicts, update it with the latest from the base branch.
   
   If you are having difficulty finding a reviewer, please reach out to the 
   community, contact details can be found here: https://flink.apache.org/what-is-flink/community/
   
   If this PR is no longer valid or desired, please feel free to close it. 
   If no activity occurs in the next 30 days, it will be automatically closed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-4364157886

   @flinkbot run azure


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on code in PR #27372:
URL: https://github.com/apache/flink/pull/27372#discussion_r3378820006


##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -44,6 +44,7 @@ import scala.collection.JavaConversions._
  * for the standard logical algebra.
  */
 class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
+  private val MaxGeneratedEnrichedKeys = 128

Review Comment:
   
   One small deviation from the literal "new metadata read at the sink": an intermediate Calc/Project between joins usually drops the redundant equated column before we reach the sink, so by the sink the equivalence is already gone - a single metadata value read there would miss it. So instead of a standalone equivalence metadata I added a small resolver UpsertKeyEquivalenceUtil.upsertKeysWithin(rel, target, mq), called from the two consumers  (canUpsertKeysWithImmutableColsSatisfyPk and StreamPhysicalSink.primaryKeysContainsUpsertKey). It threads the sink PK down the plan as a fixed target and, on top of the keys getUpsertKeys already reports, recovers the ones that fit after swapping an out-of-target column for an equi-join-equivalent partner - resolving at the deeper join where the column still exists and mapping the key back up through the projection.
   
   Since the target is the fixed (small) PK, nothing combinatorial is ever materialized, so there's no explosion. Substitution only goes toward a non-nullable column, so it's safe across outer joins, and it also covers the fused MultiJoin(inner only atm, plant to followup with outers). 
   
   Let me know what you think.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-4359995004

   Real-world case demonstrating the need.
   
   Flink 2.2.0 + Fluss 0.9, classic parent/child CDC join - sale_items.PK = (provider_id, sale_id, id) strictly extends sales.PK = (provider_id, id), with bucket key on each side covering its join key. All documented DeltaJoin preconditions hold (Fluss PK on both sides, INNER JOIN, no DELETE, delta-join.strategy=AUTO).                                                                                                                                 
   
   ``` sql
     INSERT INTO sales_with_sale_items                                                                                                                                                                                                                  
     SELECT s.provider_id, s.id AS sale_id, si.id AS sale_item_id, ...
     FROM sale_items si INNER JOIN sales s                                                                                                                                                                                                              
       ON si.provider_id = s.provider_id AND si.sale_id = s.id;
   ```                                                                                                                                                                                                                                             
     Stock 2.2.0 falls back to a regular Join and injects a SinkUpsertMaterializer:                                                                                                                                                                   
     
     +- Sink(... upsertMaterialize=[true])                                                                                                                                                                                                              
        +- Calc(...)                                           
           +- Join(leftInputSpec=[HasUniqueKey], rightInputSpec=[JoinKeyContainsUniqueKey],
                   changelogMode=[I,UB,UA], duplicateChanges=[DISALLOW])                                                                                                                                                                                
              :- TableSourceScan([sale_items])
              +- TableSourceScan([sales])                                                                                                                                                                                                               
                                                               
     This PR cherry-picked onto release-2.2.0:                                                                                                                                                                                                          
                                                               
     +- Sink(...)
        +- DeltaJoin(...)                                                                                                                                                                                                                               
           :- DropUpdateBefore +- TableSourceScan([sale_items])
           +- DropUpdateBefore +- TableSourceScan([sales])                                                                                                                                                                                              
                                                                                                                                                                                                                                                        
   Why: Base getJoinUpsertKeys returns only {si.provider_id, si.sale_id, si.id} (left's PK). The natural SELECT projects s.provider_id, s.id - bit-identical under INNER JOIN, but the Calc only retains projected columns, so the only upsert key dies. No upstream key -> SinkUpsertMaterializer ->  duplicateChanges=DISALLOW propagates -> DropUpdateBefore blocked → DeltaJoin rejected.                                                                                                             
                                                                                                                                                                                                                                                        
   This PR's enrichment derives {si.id, s.provider_id, s.id} via the equi-pairs - survives the Calc, matches the sink PK, materializer drops, DeltaJoin applies.                                                                                      
     
   The asymmetric parent/child shape (one PK strictly extends the join key, the other matches it) is the canonical CDC join - orders/order_items, users/sessions, conversations/messages, etc. A SELECT-rewrite workaround exists (project FK columns from the child instead of the parent), but the failure mode is silent and the gap isn't obvious to authors.
   
   @lincoln-lil Can you take a look, pls?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-4365088936

    @flinkbot run azure


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-4175050017

   This PR is being marked as stale since it has not had any activity in the last 90 days. 
   If you would like to keep this PR alive, please leave a comment asking for a review. 
   If the PR has merge conflicts, update it with the latest from the base branch.
   
   If you are having difficulty finding a reviewer, please reach out to the 
   community, contact details can be found here: https://flink.apache.org/what-is-flink/community/
   
   If this PR is no longer valid or desired, please feel free to close it. 
   If no activity occurs in the next 30 days, it will be automatically closed.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on code in PR #27372:
URL: https://github.com/apache/flink/pull/27372#discussion_r3378820006


##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -44,6 +44,7 @@ import scala.collection.JavaConversions._
  * for the standard logical algebra.
  */
 class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
+  private val MaxGeneratedEnrichedKeys = 128

Review Comment:
   
   One small deviation from the literal "new metadata read at the sink": an intermediate Calc/Project between joins usually drops the redundant equated column before we reach the sink, so by the sink the equivalence is already gone - a single metadata value read there would miss it. So instead of a standalone equivalence metadata I added a small resolver UpsertKeyEquivalenceUtil.upsertKeysWithin(rel, target, mq), called from the two consumers  (canUpsertKeysWithImmutableColsSatisfyPk and StreamPhysicalSink.primaryKeysContainsUpsertKey). It threads the sink PK down the plan as a fixed target and, on top of the keys getUpsertKeys already reports, recovers the ones that fit after swapping an out-of-target column for an equi-join-equivalent partner - resolving at the deeper join where the column still exists and mapping the key back up through the projection.
   
   Since the target is the fixed (small) PK, nothing combinatorial is ever materialized, so there's no explosion. Substitution only goes toward a non-nullable column, so it's safe across outer joins, and it also covers the fused MultiJoin(inner only atm). 
   
   Let me know what you think.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on code in PR #27372:
URL: https://github.com/apache/flink/pull/27372#discussion_r3378820006


##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -44,6 +44,7 @@ import scala.collection.JavaConversions._
  * for the standard logical algebra.
  */
 class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
+  private val MaxGeneratedEnrichedKeys = 128

Review Comment:
   
   One small deviation from the literal "new metadata read at the sink": an intermediate Calc/Project between joins usually drops the redundant equated column before we reach the sink, so by the sink the equivalence is already gone - a single metadata value read there would miss it. So instead of a standalone equivalence metadata I added a small resolver UpsertKeyEquivalenceUtil.upsertKeysWithin(rel, target, mq), called from the two consumers  (canUpsertKeysWithImmutableColsSatisfyPk and StreamPhysicalSink.primaryKeysContainsUpsertKey). It threads the sink PK down the plan as a fixed target and, on top of the keys getUpsertKeys already reports, recovers the ones that fit after swapping an out-of-target column for an equi-join-equivalent partner - resolving at the deeper join where the column still exists and mapping the key back up through the projection.
   
   Since the target is the fixed (small) PK, nothing combinatorial is ever materialized, so there's no explosion. Substitution only goes toward a non-nullable column, so it's safe across outer joins, and it also covers the fused MultiJoin. 
   
   Let me know what you think.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed pull request #27372: [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences
URL: https://github.com/apache/flink/pull/27372


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] Enrich upsert keys by equi-join equivalences [flink]

Posted by "flinkbot (via GitHub)" <gi...@apache.org>.
flinkbot commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-3699531857

   <!--
   Meta data
   {
     "version" : 1,
     "metaDataEntries" : [ {
       "hash" : "8e7f86238700d31f33710de144ca656419dcdc99",
       "status" : "UNKNOWN",
       "url" : "TBD",
       "triggerID" : "8e7f86238700d31f33710de144ca656419dcdc99",
       "triggerType" : "PUSH"
     } ]
   }-->
   ## CI report:
   
   * 8e7f86238700d31f33710de144ca656419dcdc99 UNKNOWN
   
   <details>
   <summary>Bot commands</summary>
     The @flinkbot bot supports the following commands:
   
    - `@flinkbot run azure` re-run the last Azure build
   </details>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-6054149688

   This PR has been closed since it has not had any activity in 120 days. 
   If you feel like this was a mistake, or you would like to continue working on it, 
   please feel free to re-open the PR and ask for a review.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on code in PR #27372:
URL: https://github.com/apache/flink/pull/27372#discussion_r3373984179


##########
flink-table/flink-table-planner/src/main/scala/org/apache/flink/table/planner/plan/metadata/FlinkRelMdUpsertKeys.scala:
##########
@@ -44,6 +44,7 @@ import scala.collection.JavaConversions._
  * for the standard logical algebra.
  */
 class FlinkRelMdUpsertKeys private extends MetadataHandler[UpsertKeys] {
+  private val MaxGeneratedEnrichedKeys = 128

Review Comment:
   Yes, I like your direction more, thank you for such a good idea 🙇 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [PR] [FLINK-38753] [table-planner] Enrich upsert keys by equi-join equivalences [flink]

Posted by "fresh-borzoni (via GitHub)" <gi...@apache.org>.
fresh-borzoni commented on PR #27372:
URL: https://github.com/apache/flink/pull/27372#issuecomment-4657484307

   @xuyangzhong Thank you for the review, addressed, PTAL 🙏 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@flink.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org