Skip to content

[GLUTEN-12504][VL] Replay a broadcast hash join against its pre-built hash table - #12738

Draft
malinjawi wants to merge 2 commits into
apache:mainfrom
malinjawi:feat/gluten-12504-bhj-hashtable-replay
Draft

[GLUTEN-12504][VL] Replay a broadcast hash join against its pre-built hash table#12738
malinjawi wants to merge 2 commits into
apache:mainfrom
malinjawi:feat/gluten-12504-bhj-hashtable-replay

Conversation

@malinjawi

@malinjawi malinjawi commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

What changes are proposed in this pull request?

Closes #12504. Stacked on #12592, please review that first.

A BHJ's build side never reaches the native operator as data. Its hash table is built once per executor and handed to the join through a process local cache, so a standalone benchmark process had nothing to join against and replayed the join against an empty build side.

Dump: VeloxRuntime walks the converted plan for hash joins that resolved to a cached table and writes each one as hashtable_{stageId}_{partitionId}_{vId}_{cacheKey}.bin.

Replay: GenericBenchmark gains --hash_table. Each file is registered with HashTableCache, so HashBuild takes its cached path and never reads the build side, and with getJoin(), so the converter chooses that path. getJoin() resolves against these only when no JVM is attached, so executors are unaffected.

How was this patch tested?

New hash_table_dump_file_test covers the dump format. Built and linked locally, including generic_benchmark.

Was this patch authored or co-authored using generative AI tooling?

Generated-by: Claude Code

…ro benchmark

getJoin() dereferenced JniHashTableContext::vm_, which is only set from
JNI_OnLoad, so converting a plan with a non-empty hashTableId crashed in a
process with no JVM. callJavaGet() now returns std::optional and getJoin()
reports a miss, the same way the JVM side cache reports one.

VeloxColumnarBatchWriter creates the parquet writer on the first batch, where it
learns the schema, so an input iterator that yields nothing left it null and
close() dereferenced it. A BHJ build side is such an iterator. close() is now a
no-op when nothing was written, and the dumper records the gap as a .empty
marker rather than reading back a file that was never created.
… hash table

A BHJ's build side is not streamed to the native operator: the hash table is
built once per executor, or on the driver and broadcast, and handed to the join
through a process local cache keyed by a hash table id. A standalone benchmark
process has no such cache, so it replayed the join against an empty build side.

VeloxRuntime now walks the converted plan for hash joins that resolved to a
cached table, serializes each with HashTableSerializer and writes it next to the
plan. GenericBenchmark gains --hash_table to load them back, registering with
HashTableCache so HashBuild takes its cached path and never reads the build
side, and with getJoin() so the converter chooses that path at all. getJoin()
resolves against those tables only when no JVM is attached, so executors are
unaffected.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Microbenchmark doesn't support BHJ

1 participant