Not exactly. Say I have a table with one row per user and want users for a given country. I could say
SELECT country_code AS country_code::multi-filter,
count(1) AS users FROM mytable GROUP BY country_code;
And I will indeed get a dropdown with country codes. But, the query is still running for all countries (and if I'm not mistaken all the filtering is on the client). For something more complex, like number of users from a country with spend over a certain amount, I want something like:
SELECT country_code AS "cc::filter",
COUNT(1) as num_users
FROM mytable
WHERE lifetime_spend > {Value from a superset dropdown}
GROUP BY country_code
I could do something like
SELECT country_code AS "cc::filter",
COUNT(1) as num_users,
lifetime_spend from .....
and then filter on the Redash side, I suppose, but that will be slower and have to deal with a lot of data I don't care about.
Has something like this been added in the last few months?
Also, Redash generally seemed to be based around the idea that you would write SQL with a few parameters in the SELECT statement and users would be content with that (which of course is true for many use cases!) We wanted to be able to add a table to Redash/Superset/Metabase/whatever and have someone who doesn't know SQL gain some insights quickly. For instance, distinct users in the last week on a given platform from a set of access logs.
Still though, I meant what I said - I had Redash up and hooked to our DB with useful charts in about 5 minutes, which was spectacular. As time went on though we realized that a lot of people could answer their questions in Superset without asking someone else to write SQL, while Redash required someone to write a query.
Superset is definitely the less mature and polished product, though, perhaps due to its ambition!