sadd alphabet A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
sscan alphabet 0 count 3

1) "8"
2) 1) "C"
   2) "M"
   3) "J"

but when iput int number to a set, count 3 will show all member

sadd number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
sscan number 0 count 3

1) "0"
2)  1) "0"
    2) "1"
    3) "2"
    4) "3"
    5) "4"
    6) "5"
    7) "6"
    8) "7"
    9) "8"
   10) "9"
   11) "10"
   12) "11"
   13) "12"
   14) "13"
   15) "14"
   16) "15"
   17) "16"
   18) "17"
   19) "18"
   20) "19"
   21) "20"
   22) "21"
   23) "22"
   24) "23"
   25) "24"
   26) "25"
   27) "26"

Comment From: enjoy-binbin

yes, sadd number 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 this will create a set with the intset encoding, and you can see this doc: https://redis.io/commands/scan/

ths The COUNT option part:

When iterating Sets encoded as intsets (small sets composed of just integers), or Hashes and Sorted Sets encoded as ziplists (small hashes and sets composed of small individual values), usually all the elements are returned in the first SCAN call regardless of the COUNT value.

and now i see the doc is a bit outupdate, in 7.0, we replaced all ziplists with listpack. In 7.2, we add listpack conding for SET. i will update the doc later

Comment From: enjoy-binbin

i seem to remember in the old past, using scan with small count in a large ziplist (2048 entries) causing a trouble on us Have we considered changing this behavior? (breaking change) i.e. let the count option actually work? @oranagra We can add some offsets to let the cursor traverse backwards in sequence, and break the loop when the count is meet. This shouldn't be any worse than what we have now (since we've now iterated over the entire list)

edit. i suppose we can do it in intset, since we can just dump to the cursor. as for listpack, i think should not be changed, because the overall time complexity has increased

nevermind, leave it as it is, it just popped into my mind

Comment From: oranagra

This is not a bug and not an unexpected behavior. the COUNT argument for SCAN doesn't really limit the number of elements you'll get (in some cases you'll get less, and usually you'll get more than you asked for, even in dict encoded collections since it scans complete dict buckets, and stops when it passed the count). The fact is that count is just some advise to redis to limit the execution complexity. for packed collections (intset, ziplist, listpack), the entire collection is expected to be rather small, and there's no reason to break it to segments. in addition to that, the scan cursor mechanism cannot provide the same guarantees, which is to still work correctly when the collection is modified during the scan (between scan calls). i.e. for dict encoded collections it grantees to always return each element that existed for the entire duration of the scan (wasn't added or deleted mid-scan) exactly once (other than some small issue with resharding IIRC).