voonhous commented on code in PR #19642:
URL: https://github.com/apache/hudi/pull/19642#discussion_r3794227564
##########
hudi-trino/src/test/java/io/trino/plugin/hudi/TestHudiSmokeTest.java:
##########
@@ -928,6 +937,26 @@ public void
testDynamicFilterEnabledPredicatePushdown(ResourceHudiTablesInitiali
assertQuery(query, "VALUES (1, 'a1', 100.0, 1000), (3, 'a3', 101.0,
1001)");
}
+ @ParameterizedTest
+ @EnumSource(
+ value = ResourceHudiTablesInitializer.TestingTable.class,
+ names = {"HUDI_MULTI_FG_PT_V6_MOR", "HUDI_MULTI_FG_PT_V8_MOR"})
+ public void
testDynamicFilterEliminatesAllSplits(ResourceHudiTablesInitializer.TestingTable
table)
+ {
+ Session session = SessionBuilder
+ .from(getSession())
+ .withDynamicFilterTimeout("10s")
+ .build();
+
+ // The build side matches no rows, so the completed dynamic filter is
NONE and the
+ // probe-side split source must report itself finished instead of
draining the queue
+ @Language("SQL") String query = "SELECT t1.id FROM " +
+ table + " t1 " +
+ "INNER JOIN " + table + " t2 ON t1.id = t2.id " +
+ "WHERE t2.price < 0";
+ assertThat(getQueryRunner().execute(session,
query).getRowCount()).isEqualTo(0);
Review Comment:
Agreed -- the bare empty-result assert also passes when the filter never
completes and the join discards a full scan. Strengthened in 651552d59bd5 with
the same EXPLAIN ANALYZE probe check the other DF tests use, pinned to `Input:
0 rows` (versus 4 without elimination); green on both table variants locally.
##########
release/release_guide.md:
##########
@@ -290,6 +290,31 @@ Here is how to go about a bug fix release.
- Go to apache/hudi repo locally and pull this branch. Here after you can work
on this branch and push to origin when need be.
- Do not forget to set the env variables from above section.
+## hudi-trino Trino pin-back
+
+On master hudi-trino tracks `trinodb/trino` master at the commit in
`trino.sha`, whose `trino.version` is a
+`-SNAPSHOT` that resolves from nowhere but a local build. A release must
depend on a released Trino, and the pin-back
+must land on the release branch before the source release is generated (see
"Build a release candidate", the Generate
+Source Release step) -- otherwise the voted tarball ships a `-SNAPSHOT` Trino
pin that cannot be built from Central.
+
+1. Wait for the latest released Trino `NNN` to be available on Maven Central.
+2. In a `trinodb/trino` checkout, find the tagged commit: `TAG_SHA=$(git
rev-list -n1 NNN)`.
+3. If the pin is behind the tag, advance master's pin to `TAG_SHA` first by
running the
+ `Hudi Trino SPI Compatibility` workflow via `workflow_dispatch` and merging
the pin PR a committer opens from the
Review Comment:
Correct, the dispatch could only pin whatever HEAD happened to be. Went with
the ref input in 651552d59bd5: `workflow_dispatch` now takes `trino_ref`
(default `master`; scheduled runs are unaffected), the trino checkout uses it,
and the guide's step 3 says to dispatch with `trino_ref=NNN` so the pin lands
exactly on the released tag.
--
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]
