SCAN count after MATCH #1546

kmatt opened this Issue Feb 10, 2014 · 1 comment


None yet
2 participants

kmatt commented Feb 10, 2014

Although the SCAN docs specifically state that the COUNT limit is applied before the MATCH pattern and thus the number of results may be less than count, this results in extra database calls when a specific number of SCAN results is needed. Being able to specify an exact number of elements returned from SCAN would be preferable.

What are the drawbacks to a SCAN implementation that continues until the number of matched items in the cursor is equal to the count parameter? Does is present performance problems like the KEYS command?


antirez commented Jul 21, 2014

@datasaur basically what you propose is antithetical to SCAN itself that was designed to don't block, so I just use a pattern that is not present in the key space, and the result is an unique unblocked full-scan of the key space. The current design allows you to select the tradeoff by using a bigger count if you have too little results, and at the same time it clearly exposes to the user the tradeoff: if you don't see results after multiple calls, you are looking for a needle inside an haystack, so probably a different design is needed (like indexing stuff into a sorted set). That's why this design was not considered.

antirez closed this Jul 21, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment