You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Wrong results when pushdown_filters is enabled (starting in 48.0.0) #16588
There are a lot of linked issues and discussions here, so it's quite possible that I missed an existing bug report, but I wanted to report an issue I encountered when enabling datafusion.execution.parquet.pushdown_filters.
@xudong963 asked in the other issue whether the issue existed in 47.0. I just tested and 47.0 gives the correct output. So the issue is somewhere between the 47.0 and 48.0 releases.
changed the title [-]Wrong results when `pushdown_filters` is enabled[/-][+]Wrong results when `pushdown_filters` is enabled (starting in 48.0.0)[/+]on Jun 28, 2025
@ianthetechie I looked at your example repo (thanks so much for providing an MRE) but I don't see the data anywhere. Maybe I'm missing something but is categories a known dataset? Without that it may be hard to repro. The query looks relatively simple and I feel like similar queries are extensively tested.
I can reproduce running this SQL in datafusion-cli:
-- Create external table pointing to the provided parquet file
CREATE EXTERNAL TABLE categories
STORED AS PARQUET
LOCATION 's3://fsq-os-places-us-east-1/release/dt=2025-06-10/categories/parquet/categories.zstd.parquet';
-- First, inspect the data structureSELECT*FROM categories LIMIT5;
-- Test with pushdown DISABLEDSETdatafusion.execution.parquet.pushdown_filters= false;
-- Query with pushdown DISABLED - establish baselineSELECTCOUNT(*)
FROM categories
WHERE level1_category_name ='Arts and Entertainment';
-- Enable pushdownSETdatafusion.execution.parquet.pushdown_filters= true;
-- Same query with pushdown ENABLED - should match baselineSELECTCOUNT(*)
FROM categories
WHERE level1_category_name ='Arts and Entertainment';
-- CleanupDROPTABLE categories;
-- Enable pushdownSETdatafusion.execution.parquet.pushdown_filters= true;
-- Create external table pointing to the provided parquet file
CREATE EXTERNAL TABLE categories
STORED AS PARQUET
LOCATION 's3://fsq-os-places-us-east-1/release/dt=2025-06-10/categories/parquet/categories.zstd.parquet';
-- Same query with pushdown ENABLED - should match baselineSELECTCOUNT(*)
FROM categories
WHERE level1_category_name ='Arts and Entertainment';
-- CleanupDROPTABLE categories;
Activity
ianthetechie commentedon Jun 28, 2025
@xudong963 asked in the other issue whether the issue existed in 47.0. I just tested and 47.0 gives the correct output. So the issue is somewhere between the 47.0 and 48.0 releases.
[-]Wrong results when `pushdown_filters` is enabled[/-][+]Wrong results when `pushdown_filters` is enabled (starting in 48.0.0)[/+]alamb commentedon Jun 28, 2025
Thanks @ianthetechie -- I have marked this issue as a regression in 48
adriangb commentedon Jul 1, 2025
@ianthetechie I looked at your example repo (thanks so much for providing an MRE) but I don't see the data anywhere. Maybe I'm missing something but is
categoriesa known dataset? Without that it may be hard to repro. The query looks relatively simple and I feel like similar queries are extensively tested.ianthetechie commentedon Jul 1, 2025
@adriangb The dataset is loaded here: https://github.com/ianthetechie/datafusion-predicate-pushdown-mre/blob/0abc24cd2f728a88e7496f0294554f0858d7c79b/src/context.rs#L12. It's coming from a public S3 bucket, and is a bit large to put in a git repo (though not excessive; the query is very fast), so I didn't bother committing the data. The example should run as-is though. Let me know if you have any issues / find otherwise!
adriangb commentedon Jul 1, 2025
Sorry I missed that!
ianthetechie commentedon Jul 1, 2025
No worries; I thought I was doing a favor trying to separate things into different files, but obviously that didn't work out ;)
adriangb commentedon Jul 1, 2025
I can reproduce running this SQL in
datafusion-cli:adriangb commentedon Jul 1, 2025
A bisect revealed the offending commit is #15769. I am investigating further.
adriangb commentedon Jul 1, 2025
This small change to the query fixes it:
alamb commentedon Jul 1, 2025
Thank you for looking into this @adriangb
adriangb commentedon Jul 1, 2025
I have a fix
adriangb commentedon Jul 1, 2025
#16646