Attempt to optimize banned user check
What does this MR do and why?
The change is behind a FF: exists_query_for_banned_users
This MR attempts to improve the IssuesFinder
DB queries by optimizing the banned user check.
- Before: all banned users were looked up via an
IN
query. - Current MR: we use an
EXISTS
query with can provide better performance forLIMIT
-ed queries.
Example when the old query performs poorly: when you look for 20 issues which matches your index perfectly, we would still load thousands of banned_users
rows for the IN
filter. With the EXISTS
query, there would be a maximum of 20 banned_users
lookups.
Optimization idea (not part of this MR)
A further optimization would be using a bloom filter where we store the banned user ids in a space-efficient data structure which allows very fast membership checks. In an ideal case, the DB would only read one row (the bloom filter hash).
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.