Pushdown physical filters to SQLExecutor#160
Conversation
| self.executor.metrics() | ||
| } | ||
|
|
||
| fn handle_child_pushdown_result( |
There was a problem hiding this comment.
| Some(self.metrics_set.clone_inner()) | ||
| } | ||
|
|
||
| fn gather_filters_for_pushdown( |
There was a problem hiding this comment.
|
Pardon my ignorance @nuno-faria , but what actual SQL backend can benefit from those filters after the sql is dispatched? Or do you parse and unparse the sql again in your use case? I'm wondering if there is a more efficient API to lazily generate sql once with dynamic filters, at least up until the Pre phase. |
@ahirner in our case we convert the dynamic filters to SQL and then wrap the original query with them. |
|
Either your engine gives you IR to layer filters on top or you reformat sql as an inner subquery. I was curious which, because I find the former interesting and the latter inefficient. |
We reformat the SQL as a subquery. I wouldn't call it inefficient since the optimizer in the backend can then pushdown the filters. |
|
Thank you @nuno-faria . I was referring to the additional unparsing. That's most likely pedantic and not relevant in practice. |
3 participants
Adds the ability for implementations of
SQLExecutorto have access to any filters generated at runtime, like dynamic filters.This adds a breaking change on the
executemethod, which receives an extrafilters: &[Arc<dyn PhysicalExpr>]argument. However, it can be safely ignored.