twalthr commented on code in PR #27508:
URL: https://github.com/apache/flink/pull/27508#discussion_r2852328126
##########
flink-table/flink-table-runtime/src/main/java/org/apache/flink/table/runtime/operators/join/stream/keyselector/AttributeBasedJoinKeyExtractor.java:
##########
@@ -288,11 +311,13 @@ private RowData buildKeyRowFromJoinedRow(
for (int i = 0; i < keyExtractors.size(); i++) {
keyRow.setField(i,
keyExtractors.get(i).getLeftSideKey(joinedRowData));
}
- return keyRow;
+ return keySerializer.toBinaryRow(keyRow).copy();
Review Comment:
I don't think that checking the state backend is considered a bad design. We
are doing this for various operators nowadays e.g. the new
SinkUpsertMaterializerV2. The state backend endpoint is new but could improve
the performance of the engine quite significantly. Our SQL operators should be
highly specialized/optimized for performance. @gustavodemorais how could a
`shouldReuseRow` flag help? For RocksDB we can also rely on the serialization
of the statement backend, for heap we need to copy.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
