Thijs

Results 416 comments of Thijs

Issue with filtering based on a timestamp partitioned column on duckdb 1.3.1

I can see that, I'm not saying these results are correct by any means, but you haven't given me enough information to debug this. You provide a *screenshot* of a...

Issue with filtering based on a timestamp partitioned column on duckdb 1.3.1

An iceberg table, does not have to be your actual data, that reproduces this problem, where filters are too aggressively filtering out data.

Issue with filtering based on a timestamp partitioned column on duckdb 1.3.1

Thanks, I've reproduced the issue I have not figured out what is going wrong yet The manifest doesnt get filtered out, neither does the data file So I'm starting to...

Issue with filtering based on a timestamp partitioned column on duckdb 1.3.1

> I think we've got a similar problem with duckdb 1.3.1 and querying an iceberg table directly from python. It returns seemingly random counts but works fine in version 1.3.0....

Compatibility issues with the DataFrame.join method of the experimental Spark API

Thanks for the report, it would be great if you could provide a direct reproduction. Your sharded code blocks are missing information, such as where df, df2, df3 and df4...

snowflake - cannot parse the metadata with duckdb v1.3.2

This sounds like #374 To fix this, duckdb-avro needs to be able to read the toplevel metadata so we can act on the "format-version" in the file, rather than on...

Result of sql(..).execute() still refers to local context variables.

Thanks for the report, I believe I discovered this issue myself a couple days ago, if it's the same issue I am aware of the cause and am working on...

Server crashes on executing "SELECT COUNT FROM iceberg_scan(...)"

This was still using the `bind_replace` architecture, this has been overhauled entirely, if the problem resurfaces feel free to re-open but I'm confident this issue is solved.

iceberg_scan() is slower than read_parquet() if multithreaded

Sanity check: you are closing and reopening the CLI between these tests? If you're not, the faster result is likely explained by caching

Elaborate on what threads=1 means w.r.t. main thread/background threads

This PR went pretty deep into what it means https://github.com/duckdb/duckdb/pull/10548