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!
SELECT country_code AS "cc::filter", COUNT(1) as num_users FROM mytable WHERE lifetime_spend > {{minimum_lifetime_spend}} GROUP BY country_code
And minimum_lifetime_spend will render as an input box. Currently we only support input boxes (of different types - number/string/date), but there is a plan to add support for dropdowns there as well.
Allowing self serving without knowing SQL is the goal, but I believe it will take time to do it right. We focus on delivering a great product for people who know SQL, and allow them to give more interactive result sets to other users using things like parameters.
So not sure if our goal is less ambitious, but we just take a different path. And that's good I guess, it would've been not interesting if everyone built the same thing, the same way :-)