tpc-h query operations aren't aligned across backends

[MarcoGorelli]

Hey

This is something which I think isn't quite right in the Polars repo either (and I've flagged it there too)

I think there's a few cases where operations are written in different orders - as dataframe libraries move towards query optimisation (🥳 ), I think it becomes more important that things be written in the same order, so that it's up to the query optimiser to reorder things

In Q5, the pandas API version is written as "filter, filter, merge, merge, merge, merge, merge"

benchmarks/tests/tpch/dask_queries.py

Lines 177 to 189 in f9eda14

	rsel = region_ds.r_name == "ASIA"
	osel = (orders_ds.o_orderdate >= date1) & (orders_ds.o_orderdate < date2)
	forders = orders_ds[osel]
	fregion = region_ds[rsel]
	jn1 = fregion.merge(nation_ds, left_on="r_regionkey", right_on="n_regionkey")
	jn2 = jn1.merge(customer_ds, left_on="n_nationkey", right_on="c_nationkey")
	jn3 = jn2.merge(forders, left_on="c_custkey", right_on="o_custkey")
	jn4 = jn3.merge(line_item_ds, left_on="o_orderkey", right_on="l_orderkey")
	jn5 = supplier_ds.merge(
	jn4,
	left_on=["s_suppkey", "s_nationkey"],
	right_on=["l_suppkey", "n_nationkey"],
	)

whereas the Polars one is written as "join, join, join, join, join, filter, filter"

benchmarks/tests/tpch/test_polars.py

Lines 192 to 202 in f9eda14

	region_ds.join(nation_ds, left_on="r_regionkey", right_on="n_regionkey")
	.join(customer_ds, left_on="n_nationkey", right_on="c_nationkey")
	.join(orders_ds, left_on="c_custkey", right_on="o_custkey")
	.join(line_item_ds, left_on="o_orderkey", right_on="l_orderkey")
	.join(
	supplier_ds,
	left_on=["l_suppkey", "n_nationkey"],
	right_on=["s_suppkey", "s_nationkey"],
	)
	.filter(pl.col("r_name") == var_1)
	.filter(pl.col("o_orderdate").is_between(var_2, var_3, closed="left"))

Likewise in a few others

---

Granted, all benchmarks are wrong, just flagging it in case it can help improve Dask's query optimiser (especially if there's a chance that it'll end up powering pandas too 💪 )

[phofl]

Thanks! This is still from the benchmarks that we copied over from Polars (so that's the reason for the same ordering as over there). We have a bunch of cases in the queries that we wrote ourselves that push filters around, so not super worried functionality wise here.

We should adjust this anyway (feel free to open a PR if you're interested :)), but not super high priority for me personally