On Mon, 26 Jan 2026 at 16:11, ywgrit <[email protected]> wrote: > > Presentation: > https://anarazel.de/talks/2018-06-01-pgcon-state-of-jit/state-of-jit.pdf. It > mentions “Future things to JIT: Aggregate & Hashjoin hash computation.” I'm > not entirely clear where this optimization specifically manifests. I tested > tpch-100G. Performance improvements for q5/11 were minimal because expression > execution constitutes a very small proportion in these two queries, leaving > little room for JIT optimization. Both queries share common hot functions: > `ExecParallelScanHashBucket` and `ExecParallelHashJoin`. However, I don't see > how these hot functions could be optimized via JIT. I'd appreciate hearing > everyone's thoughts.
I imagine Andres is talking about the computation of the hash value itself. The talk does predate [1] (from PG18), so I expect that item is no longer relevant. In [1], you can see the Hash Join hash value was obtained via ExecHashGetHashValue(), which evaluated each hash key independently (perhaps resulting in inefficient incremental tuple deformation) before calling the hash function on the resulting value. [1] moved all that into the expression evaluation code so that all hash keys are evaluated in the same expression. That allows the hash function call to be inlined when jitted. It also allowed the "keep_nulls" run-time check to be jitted away so that there's less overhead of effectively having to continually check which join type is being processed. David [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=adf97c156
