-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Filter pushdown issue with aggregating inline views and CTE's #640
Comments
@ralfbecher Hey Ralf! That's a great question! As of now the best way to approach it is with multiple queries: {
measures: [
'FoodSales.sumAmount'
],
dimensions: [
'FoodSales.item'
],
order: {
'FoodSales.sumAmount': 'desc'
},
limit: 5
} And then for others {
measures: [
'FoodSales.sumAmount'
],
filters: [{
dimensions: 'FoodSales.item',
operator: 'notEquals',
values: [...topItems]
}]
} It isn't obvious but those 2 separate queries usually faster than a big one and also easier to maintain. We're considering to make these "other" queries as part of an API. Let's use this issue to track this API enhancement. |
@paveltiunov Hi Pavel, thanks for your suggestion. I also had in mind to decompose the SQL but then we run into a pipeline approach with longer roundtrip times. However, my intention here was not to solve the top-5 "other" problem (it was just one example), and I would appreciate any solution in Cube.js for that, but to address the filter pushdown (predicate pushdown) inside the inner SELECT statement(s) or CTEs especially for aggregation queries. This means to have a control where a WHERE clause is added. And I think if we explicitly use |
@ralfbecher Could you please provide exact SQL query you need to reproduce then? |
@paveltiunov Let's have an inline view with aggregation where I want to filter on a criteria which is not part of the dimensionality (where amount > 1000, or where country = 'UK'):
|
Seconding this request - there should be an ability to pass filters into the query that are not also added to the WHERE clause. |
Filters are applied to the outer SELECT. This cannot work with aggregating inline views and CTE's (common table expressions if dimensionality is reduced. With
FILTER_PARAMS
we can push down the filter inside the inline view or CTS like this:Having this simple example with a transaction table:
and a Cube defined for aggregating top-5 with all others (typical pie chart) we want to filter for
AMOUNT < n
(eg. finding top-5 items in a lower segment):Now we define this query with the filter
AMOUNT < 1000
:This is the generated SQL:
As we see we have an additional
WHERE
clause on the outerSELECT
where we do not have theAMOUNT
field because of aggregation.My expectation is that this is not needed here because we have explicitly used
FILTER_PARAMS
for this field inside the SQL. Also, I would expect the fieldAMOUNT
would not appear in the outer SELECT since I setshown: false
in the Cube definition.Maybe there is already a solution to such kind of queries and I haven't found it yet?
The text was updated successfully, but these errors were encountered: