Skip to content

Draft POC Unified filter decoder #7503

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

zhuqi-lucas
Copy link
Contributor

@zhuqi-lucas zhuqi-lucas commented May 14, 2025

Which issue does this PR close?

Closes #.

See context here:

Rationale for this change

What changes are included in this PR?

Are there any user-facing changes?

@github-actions github-actions bot added the parquet Changes to the parquet crate label May 14, 2025
Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @zhuqi-lucas -- this is quite cool

}
};

let Some(mut raw_sel) = take_next_selection(selection, self.batch_size) else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a neat pattern -- to start with the relevant RowSelection and then potentially narrow it down using the filters


let predicate_projection = predicate.projection();

row_group
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think one potential downside of this approach is that if we have multiple filters applied, this will still fetch all the pages for all subsequent filter columns even for pages that could be ruled out by previous filter results

So like if you have predicates like

  • A = 5
  • B = 10

The code on main will fetch all pages for A = 5, but then only fetch pages for B = 10 where there were any matching rows of A

So if A = 5 was able to prune out any pages this new approach will no longer prune them out 🤔

I think in general there is going to have to be a tradeoff betwee how much post-filtered data is buffered vs simply re-decoding the column again.

Maybe we can decode each row group in multiple smaller selections to limit the buffering or something -- I will contemplate

Copy link
Contributor Author

@zhuqi-lucas zhuqi-lucas May 15, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @alamb , this is a good point, i agree with you, we will lose some optimization from this way. Need more further improvement and thinking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
parquet Changes to the parquet crate
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants