Skip to content
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

Why aren't we filtering rows by supplied filters in IterateForeignScan? #87

Open
sushrut141 opened this issue Jun 18, 2024 · 1 comment

Comments

@sushrut141
Copy link

Came across this comment where the foreign scan is created.

We have no native ability to evaluate restriction clauses

Why is this the case?
The ParquetReaders seem to be reading rows disregarding any applied filters.
The filters can be used to avoid returning rows that do not match the WHERE clauses in the query.

Why are all rows being returned as is? Will the planner re-run the filters on the returned rows?

@sushrut141
Copy link
Author

sushrut141 commented Jun 20, 2024

Hey, I would like to add this filtering support if you're open to contributions.
Can you please clarify if there was some reasoning behind not adding it initially?
Thanks

EDIT: Found the info in the docs.
https://www.postgresql.org/docs/16/fdw-planning.html

 In simple cases the FDW can just strip RestrictInfo nodes from the scan_clauses list (using extract_actual_clauses) and put all the clauses into the plan node's qual list, which means that all the clauses will be checked by the executor at run time. More complex FDWs may be able to check some of the clauses internally, in which case those clauses can be removed from the plan node's qual list so that the executor doesn't waste time rechecking them.

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

No branches or pull requests

1 participant