04:31:45 GMT <SaintMoriarty> Can I make it so when the client gets disconnected all data belonging to that session gets removed?
04:38:40 GMT <SaintMoriarty> ?
11:25:00 GMT <Guest74887> Hi, quick question, imagine that I have a set of 3000 elements, and I do sismember a lot... would be more efficient having 3000 "standard" keys and do get requests?
11:27:34 GMT <gobbe> it's at least faster
11:34:10 GMT <minus> Guest74887: should not make a difference, SISMEMBER is O(1) and so is GET/EXISTS
11:34:30 GMT <minus> a set is probably more efficient wrt storage space
11:34:51 GMT <minus> https://redis.io/commands/sismember ← shows the time complexity at the very top
11:37:15 GMT <gobbe> true, i made mistake and read smembers :/
11:40:05 GMT <minus> that obviously is O(n) :D
11:46:05 GMT <gobbe> yes
11:46:24 GMT <gobbe> maybe I should take some coffee before continuing to do my job :D
12:02:55 GMT <Guest74887> oh, thanks a lot, that was really useful.
12:39:45 GMT <aps> Hey guys, just wondering if they're a way to migrate a sorted set from one redis instance to another and merging the items in a set, instead of replacing the existing items in the target instance.
12:41:31 GMT <minus> aps: migrate them to a new key and then use the union command to merge them
12:42:42 GMT <aps> @minus got it. Thanks! :)
12:43:35 GMT <minus> that is, rename it in the old instance before migrating
12:47:33 GMT <aps> So I can use a union command across instances? 🤔
12:48:13 GMT <minus> no
12:49:56 GMT <aps> So I rename in the old instance, migrate to the new one, and then do the ZUNION. Is that correct?
12:50:02 GMT <aps> ZUNIONSTORE
12:50:13 GMT <minus> yeah, that should do the job
12:50:25 GMT <minus> you want ZUNIONSTORE probably
14:32:10 GMT <JordiGH> I've set all of my keys to cache indefinitely, and looks like I have a 3g limit on memory.
14:32:29 GMT <JordiGH> My question: when that limit hit, is there something to control expiring old keys?
14:32:37 GMT <JordiGH> *when that limit is hit
14:32:58 GMT <minus> then maxmemory 3g and maxmemory-policy allkey-lru or so must be configured
14:33:14 GMT <minus> there is no limit by default
14:33:27 GMT <minus> 3GB might be a limit if you run on 32bits
14:36:48 GMT <JordiGH> INFO reports: http://codepad.org/QVBn8tfn
14:37:29 GMT <minus> maxmemory is configured
14:37:39 GMT <minus> that is not in the default config
14:38:07 GMT <JordiGH> Okay, so this will do what I want, right? After 3 gigs, kick out the last recently used keys?
14:38:58 GMT <minus> that alone will throw an error after you hit thel imit
14:39:16 GMT <minus> well, unless you have keys configured with expiry
14:39:35 GMT <JordiGH> Oh.
14:39:36 GMT <minus> if you don't have any keys with expiry you'll need to use allkeys-lru instead
14:39:42 GMT <JordiGH> No, none of the keys have an expiry time.
14:40:04 GMT <JordiGH> Oh, so I don't want volatile-lru.
14:40:18 GMT <minus> yep
14:40:35 GMT <minus> the config file should have the meanings of those policies explained
14:41:42 GMT <JordiGH> Not sure where that file might be. AWS, y'know. But I can probably fix that.
14:42:05 GMT <minus> oh, aws
14:42:32 GMT <minus> there's also the website: https://redis.io/topics/lru-cache
14:43:07 GMT <JordiGH> Hm, CONFIG set maxmemory_policy allkeys-lru -ERR unknown command 'CONFIG'
14:43:30 GMT <JordiGH> But the docs say that's there since 2.0? Apparently I'm on version 3.2.4
14:43:31 GMT <minus> the command might have been renamed
14:43:53 GMT <minus> you can rename commands in redis in order to disabled/hide them
14:46:09 GMT <JordiGH> I wonder if that's what AWS did.
14:51:19 GMT <JordiGH> minus: Thanks for your help.