apache
Add dynamic filter (bounds) pushdown to HashJoinExec
Part of #7955.
My goal here is to lay the groundwork for pushing down joins. I am only implementing bounds pushdown because I am sure that is cheap and it will probably be quite effective in many cases. And it will be ~ easy to push down a reference to the whole hash table in a followup PR.
Another followup that can be done is to enable parent filter pushdown through HashJoinExec. Similar to FilterExec this requires adjusting parent filters for the join's projection, but we also need to check what columns each filter refers to to push it into the correct child (or not push it if it refers to columns from both children and can't be disjoint).
I tink we should also consider a heuristic for not evaluating the filter if it's not useful.
Also I think doing only the lookup is preferable above also computing / checking the bounds, I think the latter might create more overhead.
I think doing only the lookup is preferable above also computing / checking the bounds, I think the latter might create more overhead
My thought was that for some cases the bounds checks are going to be quite effective at pruning and they should always be cheap to compute and cheap to apply. I'm surprised you say that they might create a lot of overhead?
I think doing only the lookup is preferable above also computing / checking the bounds, I think the latter might create more overhead
My thought was that for some cases the bounds checks are going to be quite effective at pruning and they should always be cheap to compute and cheap to apply. I'm surprised you say that they might create a lot of overhead?
Maybe I should articulate it a bit more.
- If we are only filtering out based on statistics, min/max might make sense to quickly filter out large chunks of rows.
- If we are filtering on values (e.g. filter pushdown) - I think it makes sense to only filter on the shared hashmap and not bothering with the min/max values - creating hashes and doing a single table lookup is quite fast, so I think we want to avoid to also evaluate the min/max expression (at least for all rows).
I think it also makes sense to also thing about a heuristic we want to use to use this pushdown only when we think it might be useful - e.g. the left side is much smaller than the right side, or we know (based on column statistics) it will filter out rows.
I think it makes sense to only filter on the shared hashmap and not bothering with the min/max values - creating hashes and doing a single table lookup is quite fast, so I think we want to avoid to also evaluate the min/max expression (at least for all rows)
I'm surprised that the hash table lookup, even if O(1), has such a small constant factor that its ~ a couple of binary comparisons. That said a reason to still do both is stats and filter caching: simple filters like col >= 123 and col <= 456 can be used for stats pruning and can easily be cached (for example for filter caching based indexing). So even if performance is not strictly better there is still something to be said for including a simple filter in addition to the hash table lookup.
I think it also makes sense to also thing about a heuristic we want to use to use this pushdown only when we think it might be useful - e.g. the left side is much smaller than the right side, or we know (based on column statistics) it will filter out rows
Datafusion is generally not great at these things: we often don't have enough stats / info to make decisions like this.
I think it makes sense to only filter on the shared hashmap and not bothering with the min/max values - creating hashes and doing a single table lookup is quite fast, so I think we want to avoid to also evaluate the min/max expression (at least for all rows)
I'm surprised that the hash table lookup, even if O(1), has such a small constant factor that its ~ a couple of binary comparisons. That said a reason to still do both is stats and filter caching: simple filters like
col >= 123 and col <= 456can be used for stats pruning and can easily be cached (for example for filter caching based indexing). So even if performance is not strictly better there is still something to be said for including a simple filter in addition to the hash table lookup.
It's hard to say generally, but a hashtable lookup which fits into cache on a u64 key can be really fast.
It's hard to say generally, but a hashtable lookup which fits into cache on a
u64key can be really fast.
I guess only benchmarks can tell. But I still think the scalar bounds are worth keeping for stats pruning reasons.
To share some experience, we recently added some similar pushdown for HashJoinExec (at Coralogix) using sharing of Arc<JoinLeftData> / comparing column hashes and it is seems so far very effective with predicate pushdown enabled.
I was originally planning on keeping this PR smaller but it's been growing so I might as well add the Arc<LeftData> :)
I was originally planning on keeping this PR smaller but it's been growing so I might as well add the Arc :)
Feel free to PR it however you like ;)
@Dandandan any chance you'd be willing to contribute your implementation of sharing Arc<LeftData> so we use something we know is working / I don't have to re-invent the wheel? I think you can just push it to this branch.
@alamb I'd be interested to see what benchmarks say if you don't mind kicking them off?
@alamb I'd be interested to see what benchmarks say if you don't mind kicking them off?
IIRC, the optimization will speed up tpch benchmark, we may run it directly. Or directly construct a small table and probe big table to see the effect.
🤖 ./gh_compare_branch.sh Benchmark Script Running
Linux aal-dev 6.11.0-1015-gcp #15~24.04.1-Ubuntu SMP Thu Apr 24 20:41:05 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing hash-join-pushdown (ab8b2e6315a3352b31d3b90da4c7bb37dbce5b70) to 59143c144d0f11265b7e33421fd6c3733b6ae26e diff
Benchmarks: tpch_mem clickbench_partitioned clickbench_extended
Results will be posted here when complete
@Dandandan any chance you'd be willing to contribute your implementation of sharing
Arc<LeftData>so we use something we know is working / I don't have to re-invent the wheel? I think you can just push it to this branch.
I'll try to have a look soon but don't know when I'll have some space for it yet!
🤖: Benchmark completed
Details
Comparing HEAD and hash-join-pushdown
--------------------
Benchmark clickbench_extended.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ QQuery 0 │ 1962.99 ms │ 1960.97 ms │ no change │
│ QQuery 1 │ 688.10 ms │ 735.65 ms │ 1.07x slower │
│ QQuery 2 │ 1332.88 ms │ 1416.49 ms │ 1.06x slower │
│ QQuery 3 │ 657.85 ms │ 653.72 ms │ no change │
│ QQuery 4 │ 1371.75 ms │ 1356.13 ms │ no change │
│ QQuery 5 │ 15278.08 ms │ 15524.22 ms │ no change │
│ QQuery 6 │ 2017.37 ms │ 2082.79 ms │ no change │
│ QQuery 7 │ 2063.13 ms │ 2021.54 ms │ no change │
└──────────────┴─────────────┴────────────────────┴──────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ Total Time (HEAD) │ 25372.15ms │
│ Total Time (hash-join-pushdown) │ 25751.52ms │
│ Average Time (HEAD) │ 3171.52ms │
│ Average Time (hash-join-pushdown) │ 3218.94ms │
│ Queries Faster │ 0 │
│ Queries Slower │ 2 │
│ Queries with No Change │ 6 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴────────────┘
--------------------
Benchmark clickbench_partitioned.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 0 │ 2.18 ms │ 2.26 ms │ no change │
│ QQuery 1 │ 33.15 ms │ 34.35 ms │ no change │
│ QQuery 2 │ 83.08 ms │ 80.97 ms │ no change │
│ QQuery 3 │ 94.65 ms │ 98.73 ms │ no change │
│ QQuery 4 │ 640.05 ms │ 599.48 ms │ +1.07x faster │
│ QQuery 5 │ 889.72 ms │ 864.15 ms │ no change │
│ QQuery 6 │ 2.25 ms │ 2.33 ms │ no change │
│ QQuery 7 │ 37.91 ms │ 37.43 ms │ no change │
│ QQuery 8 │ 857.21 ms │ 866.70 ms │ no change │
│ QQuery 9 │ 1183.15 ms │ 1190.70 ms │ no change │
│ QQuery 10 │ 253.21 ms │ 268.22 ms │ 1.06x slower │
│ QQuery 11 │ 289.40 ms │ 289.43 ms │ no change │
│ QQuery 12 │ 875.27 ms │ 902.01 ms │ no change │
│ QQuery 13 │ 1244.98 ms │ 1293.02 ms │ no change │
│ QQuery 14 │ 804.00 ms │ 838.79 ms │ no change │
│ QQuery 15 │ 789.50 ms │ 796.05 ms │ no change │
│ QQuery 16 │ 1606.04 ms │ 1650.66 ms │ no change │
│ QQuery 17 │ 1586.37 ms │ 1639.90 ms │ no change │
│ QQuery 18 │ 2880.02 ms │ 2949.30 ms │ no change │
│ QQuery 19 │ 87.23 ms │ 87.08 ms │ no change │
│ QQuery 20 │ 1134.16 ms │ 1184.12 ms │ no change │
│ QQuery 21 │ 1280.50 ms │ 1328.58 ms │ no change │
│ QQuery 22 │ 2126.21 ms │ 2200.67 ms │ no change │
│ QQuery 23 │ 7372.53 ms │ 7690.34 ms │ no change │
│ QQuery 24 │ 459.72 ms │ 482.54 ms │ no change │
│ QQuery 25 │ 393.66 ms │ 405.90 ms │ no change │
│ QQuery 26 │ 523.87 ms │ 534.28 ms │ no change │
│ QQuery 27 │ 1527.62 ms │ 1565.71 ms │ no change │
│ QQuery 28 │ 11958.57 ms │ 11946.80 ms │ no change │
│ QQuery 29 │ 526.30 ms │ 525.65 ms │ no change │
│ QQuery 30 │ 779.74 ms │ 810.76 ms │ no change │
│ QQuery 31 │ 809.91 ms │ 846.36 ms │ no change │
│ QQuery 32 │ 2568.92 ms │ 2529.35 ms │ no change │
│ QQuery 33 │ 3216.34 ms │ 3247.30 ms │ no change │
│ QQuery 34 │ 3217.53 ms │ 3308.66 ms │ no change │
│ QQuery 35 │ 1255.14 ms │ 1244.00 ms │ no change │
│ QQuery 36 │ 124.75 ms │ 123.15 ms │ no change │
│ QQuery 37 │ 51.39 ms │ 54.53 ms │ 1.06x slower │
│ QQuery 38 │ 121.36 ms │ 121.71 ms │ no change │
│ QQuery 39 │ 192.92 ms │ 194.83 ms │ no change │
│ QQuery 40 │ 42.47 ms │ 42.25 ms │ no change │
│ QQuery 41 │ 38.02 ms │ 38.90 ms │ no change │
│ QQuery 42 │ 33.82 ms │ 32.66 ms │ no change │
└──────────────┴─────────────┴────────────────────┴───────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ Total Time (HEAD) │ 53994.84ms │
│ Total Time (hash-join-pushdown) │ 54950.62ms │
│ Average Time (HEAD) │ 1255.69ms │
│ Average Time (hash-join-pushdown) │ 1277.92ms │
│ Queries Faster │ 1 │
│ Queries Slower │ 2 │
│ Queries with No Change │ 40 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴────────────┘
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ QQuery 1 │ 102.11 ms │ 100.28 ms │ no change │
│ QQuery 2 │ 20.16 ms │ 21.52 ms │ 1.07x slower │
│ QQuery 3 │ 33.16 ms │ 33.76 ms │ no change │
│ QQuery 4 │ 18.97 ms │ 19.02 ms │ no change │
│ QQuery 5 │ 50.37 ms │ 51.37 ms │ no change │
│ QQuery 6 │ 11.99 ms │ 11.87 ms │ no change │
│ QQuery 7 │ 88.26 ms │ 100.63 ms │ 1.14x slower │
│ QQuery 8 │ 24.72 ms │ 26.26 ms │ 1.06x slower │
│ QQuery 9 │ 54.05 ms │ 57.56 ms │ 1.07x slower │
│ QQuery 10 │ 43.38 ms │ 43.87 ms │ no change │
│ QQuery 11 │ 11.29 ms │ 11.81 ms │ no change │
│ QQuery 12 │ 34.83 ms │ 40.14 ms │ 1.15x slower │
│ QQuery 13 │ 26.11 ms │ 26.58 ms │ no change │
│ QQuery 14 │ 9.77 ms │ 10.23 ms │ no change │
│ QQuery 15 │ 19.70 ms │ 19.28 ms │ no change │
│ QQuery 16 │ 19.18 ms │ 18.99 ms │ no change │
│ QQuery 17 │ 96.32 ms │ 95.92 ms │ no change │
│ QQuery 18 │ 198.10 ms │ 221.52 ms │ 1.12x slower │
│ QQuery 19 │ 25.57 ms │ 26.41 ms │ no change │
│ QQuery 20 │ 31.84 ms │ 31.60 ms │ no change │
│ QQuery 21 │ 148.56 ms │ 161.40 ms │ 1.09x slower │
│ QQuery 22 │ 15.50 ms │ 14.99 ms │ no change │
└──────────────┴───────────┴────────────────────┴──────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1083.94ms │
│ Total Time (hash-join-pushdown) │ 1145.03ms │
│ Average Time (HEAD) │ 49.27ms │
│ Average Time (hash-join-pushdown) │ 52.05ms │
│ Queries Faster │ 0 │
│ Queries Slower │ 7 │
│ Queries with No Change │ 15 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴───────────┘
Looks like not much change, maybe even some slowdowns. I'll try to address https://github.com/apache/datafusion/pull/16445#discussion_r2154953337. Also probably worth breaking up this PR into enabling filters to pass through HashJoinExec (and make that implementation shared across join exec's) and a separate PR to enable HashJoinExec to produce dynamic filters.
🤖: Benchmark completed
Details
I think this is about to expect from these benchmarks and min/max pruning. Most of the data (all?) in TPC-H is randomly generated data with good distribution which makes min/max based pruning not effective as it can not prune any files. Clickbench doesn't have joins.
We probably have to minimize the overhead of computing min/max and see if we're not getting regressions on other benchmarks. Perhaps we should also skip if the build side is too large? The larger the build side the higher the overhead of computing min/max bounds and created fillters generally become less selective.
Perhaps a benchmark could be found/created that shows some more benefit with min/max pruning.
We probably have to minimize the overhead of computing min/max and see if we're not getting regressions on other benchmarks. Perhaps we should also skip if the build side is too large? The larger the build side the higher the overhead of computing min/max bounds and created fillters generally become less selective.
Makes a lot of sense. I suppose if we build the min/max while we build the hash table it should be even lower cost.
I think this is about to expect from these benchmarks and min/max pruning. Most of the data (all?) in TPC-H is randomly generated data with good distribution which makes min/max based pruning not effective as it can not prune any files. Clickbench doesn't have joins.
Ah masked sense. The use case that I really care about is joins on ULIDs where the cardinality is going to be very high and the build side may have 1M rows but the min/max bounds restrict it to a small fraction of the ULID space. I imagine it would be the same with SERIAL PKs and other cases with temporal correlations.
I've pulled out part of this PR, the part about pushing filters down through HashJoinExec plus some new changes to the filter pushdown APIs into https://github.com/apache/datafusion/pull/16642
Btw here's an article that explains how DuckDB does join filter pushdown. It sounds like they only push down min/max filters: https://duckdb.org/2024/09/09/announcing-duckdb-110.html#dynamic-filter-pushdown-from-joins
I think I've addressed all of the feedback and rebased on main / changes broken out into other PRs. @Dandandan @xudong963 I've tagged you both for review.
@alamb would you mind kicking off benchmarks?
🤖 ./gh_compare_branch.sh Benchmark Script Running
Linux aal-dev 6.11.0-1016-gcp #16~24.04.1-Ubuntu SMP Wed May 28 02:40:52 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing hash-join-pushdown (b135cd8614af0131d5e1484216b84499f37fe465) to d376a32f1f78d26a760c261878054bb1328800cc diff using: tpch_mem clickbench_partitioned clickbench_extended
Results will be posted here when complete
🤖: Benchmark completed
Details
Comparing HEAD and hash-join-pushdown
--------------------
Benchmark clickbench_extended.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 0 │ 1936.73 ms │ 1977.69 ms │ no change │
│ QQuery 1 │ 762.69 ms │ 763.75 ms │ no change │
│ QQuery 2 │ 1481.87 ms │ 1466.68 ms │ no change │
│ QQuery 3 │ 687.14 ms │ 648.45 ms │ +1.06x faster │
│ QQuery 4 │ 1362.81 ms │ 1405.27 ms │ no change │
│ QQuery 5 │ 14887.33 ms │ 14948.71 ms │ no change │
│ QQuery 6 │ 2040.21 ms │ 2100.60 ms │ no change │
│ QQuery 7 │ 1859.25 ms │ 1911.89 ms │ no change │
└──────────────┴─────────────┴────────────────────┴───────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ Total Time (HEAD) │ 25018.03ms │
│ Total Time (hash-join-pushdown) │ 25223.04ms │
│ Average Time (HEAD) │ 3127.25ms │
│ Average Time (hash-join-pushdown) │ 3152.88ms │
│ Queries Faster │ 1 │
│ Queries Slower │ 0 │
│ Queries with No Change │ 7 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴────────────┘
--------------------
Benchmark clickbench_partitioned.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ QQuery 0 │ 2.56 ms │ 2.22 ms │ +1.15x faster │
│ QQuery 1 │ 35.52 ms │ 33.65 ms │ +1.06x faster │
│ QQuery 2 │ 83.47 ms │ 82.33 ms │ no change │
│ QQuery 3 │ 98.75 ms │ 99.65 ms │ no change │
│ QQuery 4 │ 589.45 ms │ 609.21 ms │ no change │
│ QQuery 5 │ 853.26 ms │ 893.98 ms │ no change │
│ QQuery 6 │ 2.30 ms │ 2.23 ms │ no change │
│ QQuery 7 │ 39.08 ms │ 39.01 ms │ no change │
│ QQuery 8 │ 846.57 ms │ 866.28 ms │ no change │
│ QQuery 9 │ 1192.91 ms │ 1175.10 ms │ no change │
│ QQuery 10 │ 257.51 ms │ 260.38 ms │ no change │
│ QQuery 11 │ 293.94 ms │ 292.24 ms │ no change │
│ QQuery 12 │ 877.37 ms │ 896.65 ms │ no change │
│ QQuery 13 │ 1238.00 ms │ 1291.84 ms │ no change │
│ QQuery 14 │ 826.31 ms │ 833.51 ms │ no change │
│ QQuery 15 │ 792.69 ms │ 800.79 ms │ no change │
│ QQuery 16 │ 1597.34 ms │ 1619.89 ms │ no change │
│ QQuery 17 │ 1573.03 ms │ 1627.82 ms │ no change │
│ QQuery 18 │ 2835.98 ms │ 2880.59 ms │ no change │
│ QQuery 19 │ 86.15 ms │ 88.40 ms │ no change │
│ QQuery 20 │ 1118.68 ms │ 1177.86 ms │ 1.05x slower │
│ QQuery 21 │ 1262.10 ms │ 1328.57 ms │ 1.05x slower │
│ QQuery 22 │ 2066.92 ms │ 2236.89 ms │ 1.08x slower │
│ QQuery 23 │ 7344.24 ms │ 7580.33 ms │ no change │
│ QQuery 24 │ 444.04 ms │ 457.65 ms │ no change │
│ QQuery 25 │ 301.35 ms │ 313.55 ms │ no change │
│ QQuery 26 │ 437.08 ms │ 446.77 ms │ no change │
│ QQuery 27 │ 1521.59 ms │ 1569.90 ms │ no change │
│ QQuery 28 │ 11853.42 ms │ 12776.43 ms │ 1.08x slower │
│ QQuery 29 │ 520.67 ms │ 522.14 ms │ no change │
│ QQuery 30 │ 778.74 ms │ 798.51 ms │ no change │
│ QQuery 31 │ 795.04 ms │ 802.20 ms │ no change │
│ QQuery 32 │ 2425.30 ms │ 2434.52 ms │ no change │
│ QQuery 33 │ 3152.55 ms │ 3222.42 ms │ no change │
│ QQuery 34 │ 3241.80 ms │ 3218.07 ms │ no change │
│ QQuery 35 │ 1285.41 ms │ 1276.66 ms │ no change │
│ QQuery 36 │ 120.40 ms │ 125.16 ms │ no change │
│ QQuery 37 │ 50.62 ms │ 51.33 ms │ no change │
│ QQuery 38 │ 121.37 ms │ 120.85 ms │ no change │
│ QQuery 39 │ 188.72 ms │ 200.24 ms │ 1.06x slower │
│ QQuery 40 │ 41.17 ms │ 42.82 ms │ no change │
│ QQuery 41 │ 40.66 ms │ 37.95 ms │ +1.07x faster │
│ QQuery 42 │ 32.46 ms │ 32.62 ms │ no change │
└──────────────┴─────────────┴────────────────────┴───────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━┩
│ Total Time (HEAD) │ 53266.50ms │
│ Total Time (hash-join-pushdown) │ 55169.23ms │
│ Average Time (HEAD) │ 1238.76ms │
│ Average Time (hash-join-pushdown) │ 1283.01ms │
│ Queries Faster │ 3 │
│ Queries Slower │ 5 │
│ Queries with No Change │ 35 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴────────────┘
--------------------
Benchmark tpch_mem_sf1.json
--------------------
┏━━━━━━━━━━━━━━┳━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┓
┃ Query ┃ HEAD ┃ hash-join-pushdown ┃ Change ┃
┡━━━━━━━━━━━━━━╇━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━┩
│ QQuery 1 │ 99.04 ms │ 100.58 ms │ no change │
│ QQuery 2 │ 20.94 ms │ 20.34 ms │ no change │
│ QQuery 3 │ 32.40 ms │ 33.10 ms │ no change │
│ QQuery 4 │ 17.88 ms │ 18.93 ms │ 1.06x slower │
│ QQuery 5 │ 49.33 ms │ 50.27 ms │ no change │
│ QQuery 6 │ 11.85 ms │ 11.99 ms │ no change │
│ QQuery 7 │ 85.41 ms │ 89.71 ms │ 1.05x slower │
│ QQuery 8 │ 24.66 ms │ 23.71 ms │ no change │
│ QQuery 9 │ 54.04 ms │ 52.89 ms │ no change │
│ QQuery 10 │ 43.01 ms │ 42.22 ms │ no change │
│ QQuery 11 │ 11.40 ms │ 11.27 ms │ no change │
│ QQuery 12 │ 34.76 ms │ 35.10 ms │ no change │
│ QQuery 13 │ 26.29 ms │ 26.60 ms │ no change │
│ QQuery 14 │ 9.72 ms │ 9.95 ms │ no change │
│ QQuery 15 │ 18.90 ms │ 19.07 ms │ no change │
│ QQuery 16 │ 18.18 ms │ 18.11 ms │ no change │
│ QQuery 17 │ 97.90 ms │ 97.01 ms │ no change │
│ QQuery 18 │ 199.45 ms │ 194.61 ms │ no change │
│ QQuery 19 │ 25.11 ms │ 24.59 ms │ no change │
│ QQuery 20 │ 32.00 ms │ 31.28 ms │ no change │
│ QQuery 21 │ 143.48 ms │ 145.18 ms │ no change │
│ QQuery 22 │ 14.39 ms │ 14.39 ms │ no change │
└──────────────┴───────────┴────────────────────┴──────────────┘
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━┓
┃ Benchmark Summary ┃ ┃
┡━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━┩
│ Total Time (HEAD) │ 1070.16ms │
│ Total Time (hash-join-pushdown) │ 1070.91ms │
│ Average Time (HEAD) │ 48.64ms │
│ Average Time (hash-join-pushdown) │ 48.68ms │
│ Queries Faster │ 0 │
│ Queries Slower │ 2 │
│ Queries with No Change │ 20 │
│ Queries with Failure │ 0 │
└───────────────────────────────────┴───────────┘
It did run
Benchmark tpch_mem_sf1.json
I can run whatever benchmark you want - just let me know