Thijs

Yea Gabor ran into this issue about a week ago actually and I suspect as much, I'll have to see if we can delay setting these settings until the extension...

Hey thanks for raising the issue, did you also raise a corresponding issue on Arrow? As I mentioned this is caused by pushdown of the filter into Arrow, they are...

That likely doesn't get pushed down, so yes, please make an issue in Arrow 👍

Also slightly unrelated to this PR, but more generically towards `test_filter_pushdown.py` I made a start on improving the test by combining it with `test_all_types()` What we currently do is hardcoding...

``` D select ('-170141183460469231731687303715884105728'::HUGEINT)::DECIMAL(38,0); Conversion Error: Could not cast value -170141183460469231731687303715884105728 to DECIMAL(38,0) LINE 1: ...0469231731687303715884105728'::HUGEINT)::DECIMAL(38,0); ``` This looks like it should be fixed if we're going to export (U)HUGEINT...

Should probably wait to be reviewed after #11529 is merged, so we can measure the performance improvement

I tried to add an optimization to not require a lock for in-progress batches, and let that data live only in the local state To my surprise this caused an...

Actually, that makes no sense? If the batch would not be completed, the new "minimum batch" could(should) not be greater than that batch

First I was writing the minimum batch directly to the read queue, removing that fixed the issues I was having. I think at smaller buffer sizes this is a bit...

Even with this diff we're not getting equivalent behavior ```patch diff --git a/src/include/duckdb/main/buffered_data/batched_buffered_data.hpp b/src/include/duckdb/main/buffered_data/batched_buffered_data.hpp index 906ec8c028..e7edb9122c 100644 --- a/src/include/duckdb/main/buffered_data/batched_buffered_data.hpp +++ b/src/include/duckdb/main/buffered_data/batched_buffered_data.hpp @@ -68,9 +68,9 @@ private: deque read_queue; idx_t read_queue_capacity;...