Is your feature request related to a problem? Please describe.
Users of cudf-polars can run in to the situation where their (potentially complicated) query doesn't (yet) run on the GPU because we have not implemented support for all of the polars features they are using.
Right now, our fallback mechanism is to fail fast on the first unsupported feature. This works from a correctness point of view, but has some drawbacks:
Submitting new feature requests to get a query to run is an iterative (and potentially long-winded process): the first missing feature is requested, only to find that something else is now not supported
Consequently, especially if we get these from external users who do not run on bleeding edge nightlies, they might have to wait multiple releases for their query to work (since they must wait to see "what's next").
Describe the solution you'd like
Instead, we should implement a mechanism whereby we traverse the entire query, collecting all the pieces that are not supported, and then raise an error for fallback, reporting all the (unique) unsupported pieces.
This would allow reports for unsupported queries to indicate all the missing pieces, and help us to prioritise things.
Is your feature request related to a problem? Please describe.
Users of cudf-polars can run in to the situation where their (potentially complicated) query doesn't (yet) run on the GPU because we have not implemented support for all of the polars features they are using.
Right now, our fallback mechanism is to fail fast on the first unsupported feature. This works from a correctness point of view, but has some drawbacks:
Describe the solution you'd like
Instead, we should implement a mechanism whereby we traverse the entire query, collecting all the pieces that are not supported, and then raise an error for fallback, reporting all the (unique) unsupported pieces.
This would allow reports for unsupported queries to indicate all the missing pieces, and help us to prioritise things.