test(tpcds): add query 64

[gforsyth]

So this should probably not get merged yet? Or we can merge it and mark the
DuckDB failure and investigate further.

My notes so far:

There is some weird stuff happening only inside Pytest when running
this query on DuckDB. This doesn't happen with any other tpc-ds
queries, and the query in question seems to run without issue on the
other backends that can run the tpc-ds queries.

If I generate sf=1 tpc-ds data in the DuckDB CLI, then run the included
sql file (which is the SQL generated by Ibis for this query), it runs in
about half a second.

If I %load ibis_tpcds_64_local.py and then run the expr there (which
is a copy-paste of the test code), it takes about half a second.

If I remove the pytest.timeout from the tpc_test decorator, this
same query, even at sf=.45 (which is empty at that size), takes
minutes to run.

I also thought it might be the difference between using memory as the catalog instead of tpcds, but no, if I create tpcds.ddb, then create the tables in there, it still runs very quickly.

[cpcloud]

This query is absolutely monstrous.

[gforsyth]

ok, well, it passes on the other backends and the timeout will handle duckdb for now.

I'm also wondering, for the sake of correctness checks, if we should shunt the tpcds data creation into CI at sf=1

[gforsyth]

oh FFS, of course it doesn't timeout on some of the DuckDB jobs

[gforsyth]

This query is cursed

[cpcloud]

The ClickHouse timeout also does not surprise me, but it also seems to trigger what looks like a resource leakage: the remaining TPC-DS queries cannot run, because the client from query 64 appears to still be hanging around.

[cpcloud]

Two totally weird facts:

1. .tmp grows quite large while waiting for the query to finish
2. Loading TPC-DS data using CREATE TABLE instead of CREATE VIEW allows the query to finish on DuckDB quickly.

[cpcloud]

Here's a stripped down version of the query that has all the same annoying and mysterious characteristics we're observing:

   @tpc_test("ds", result_is_empty=True)
   def test_64(store_sales, customer_demographics):
       cd1 = customer_demographics
       cd2 = customer_demographics.view()

       expr = (
           store_sales.join(cd1, _.ss_cdemo_sk == cd1.cd_demo_sk)
           .join(
               cd2[["cd_marital_status"]], cd1.cd_marital_status != cd2.cd_marital_status
           )
           .select(cd1.cd_marital_status)
           .limit(1)
       )

       return expr

[cpcloud]

Found a reproducer without pytest:

import duckdb


con = duckdb.connect()
sql = """
SELECT
 t3.cd_marital_status
FROM read_parquet('ci/ibis-testing-data/tpcds/sf=0.45/parquet/store_sales.parquet') AS t2
JOIN read_parquet('ci/ibis-testing-data/tpcds/sf=0.45/parquet/customer_demographics.parquet') AS t3
 ON ss_cdemo_sk = cd_demo_sk
JOIN read_parquet('ci/ibis-testing-data/tpcds/sf=0.45/parquet/customer_demographics.parquet') AS t4
 ON t3.cd_marital_status <> t4.cd_marital_status
LIMIT 1
"""
result = con.sql(sql)
result = result.arrow()
assert len(result) == 1

[cpcloud]

Reported upstream here duckdb/duckdb#13657

[cpcloud]

Since this is fixed upstream already and the DuckDB release is out soon, I'll suggest that for now we alter our duckdb/conftest.py to create tables instead of views.

Not entirely sure what to do about ClickHouse yet.

[cpcloud]

Thank you for chugging through this abomination.

[cpcloud]

Snowflake passing query 64:

❯ pytest -m snowflake ibis/backends/tests/tpc/ds/test_queries.py -k 64 -q
.                                                                                                                                                                                              [100%]
1 passed, 1980 deselected in 18.66s