[gleb]

The example doesn't quite make sense:

  SELECT user_id IN (SELECT DISTINCT user_id FROM user_actions);

is not valid SQL. You may mean something like:

  SELECT 123 IN (SELECT DISTINCT user_id FROM user_actions);

which is a strange query, as it's equivalent to:

  SELECT 123 IN (SELECT user_id FROM user_actions);

[usman-m]

Oops, it was meant to be:

  SELECT <user_id> FROM (SELECT DISTINCT user_id FROM user_actions);

You're absolutely right that both those queries will give the same result. I guess I was trying to motivate the basic problem of finding whether some user exists in a set of users, and `SELECT DISTINCT` is the SQL way of representing a set.

Fixed the post, thanks!

[gleb]

I'd put more effort into setting up a believable problem in these kind of posts, before presenting a solution. Much like in a company pitch, it's hard to understand the value of product if you don't understand what problem it is trying to solve.

It doesn't help that using unnecessary DISTINCTs is subqueries is a common performance problem in novice SQL. Why people do that I don't really understand, but they do.

That's the thing about probabilistic data structures - I've never seen a real-world performance problem in SQL where they would have been helpful. I really would like to have an "aha" moment where somebody shows me one.

Probabilistic data structures do seem like a natural match for streaming databases, but that's different.

[teddyh]

Wouldn’t

  SELECT EXISTS (SELECT 1 FROM user_actions WHERE user_id = 123);

lead to a better execution plan?