11:45:23 GMT <DavidFromBE> hi
11:46:10 GMT <DavidFromBE> is it possible to use zremrangebyscore for multiple sorted set under a certain key in one commande ?
11:51:31 GMT <DavidFromBE> something like zremrangebyscore users:* 0 -1 but that doesn't work obviously
11:54:04 GMT <badboy_> there are no multiple sorted set under a certain key
11:54:14 GMT <badboy_> and Redis does not support patterns in place of key names
11:56:46 GMT <DavidFromBE> badboy_: say i have sorted set 1 : users:john and sorted set 2 : users:jane
11:57:24 GMT <DavidFromBE> zremrangebyscore users:john 0 -1 and zremrangebyscore users:jane 0 -1 is what i want to do, in one commande
11:57:28 GMT <DavidFromBE> is that possible ?
11:57:33 GMT <badboy_> no
11:57:55 GMT <badboy_> also 0 -1 makes no sense in zremrangebyscore?
11:58:08 GMT <badboy_> why would you want to do it in a single command? why not just both commands?
11:58:11 GMT <DavidFromBE> yeah sorry about that, mixing things up
11:59:28 GMT <DavidFromBE> anyways, i have lots of sorted sets under users (to keep that example), and i want to programatically "trim" these sorted set
11:59:43 GMT <DavidFromBE> i'm using nodejs and i do this in a loop
12:00:13 GMT <DavidFromBE> but i wanted to know if it could be achieved more efficiently
12:00:51 GMT <badboy_> pipeline it
12:02:55 GMT <DavidFromBE> ok tks
12:44:56 GMT <sembiance> so I did a simple `INCR a 1` in latest redis 4.0rc2 and then `MEMORY USAGE a` reports it takes 49 bytes! Now I know redis stores regular keys as strings, but this seems astonishingly wasteful. Is it actually using less behind the scenes? Is `MEMORY USAGE` just reporting incorrectly? Does redis look at string, see it's just a single digit and store it as a bits/bytes instead of a string? or is it all ascii underneath with 49 bytes allocated?
12:45:28 GMT <sembiance> by the way, I'm sure behavior is probably the same in redis 3.2, just thought I'd use 4.0rc2 since it introduces the MEMORY command
12:48:18 GMT <sembiance> likewise, `HSET ha a 1` and `HINCRBY hb a 1` both come back as '65 bytes' when using `MEMORY USAGE ha` and `MEMORY USAGE hb`
12:48:58 GMT <sembiance> I thought I remember reading a few years ago about some awesome behind the scenes compression that redis does to reduce memory usage for small keys like this, but not sure if I mis-remember that or if it's just not being taken into account with the `MEMORY USAGE` command
12:54:16 GMT <sembiance> Ok, as I read some more stuff, I'm pretty sure for hashtables at least, behind the scenes far less memory is used. Quote "Redis has a shared pool of integers less than 10000. This shared pool of objects is used whenever the key or value in a hashtable is an integer less than 10000." from According to https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-Memory-Optimization
12:55:14 GMT <sembiance> in fact that URL has tons of useful information. not sure how up to date it is, but it mentions how string keys do indeed have a pretty big overhead
12:56:01 GMT <sembiance> guess I should ensure as much as possible that I'm using hashes to take advantage of hash-zipmap-max-entries
12:57:26 GMT <sembiance> which doesn't appear to exist anymore...hrm
12:57:45 GMT <sembiance> ahh, just renamed to hash-max-ziplist-entries
13:03:42 GMT <sembiance> so my guess is MEMORY USAGE isn't reporting exact memory usage for that key, that it's probably more of a rough estimate
13:13:35 GMT <sembiance> so I ran a redis 4.0rc2 dump through redis-rdb-tools with it's memory analysis, it says my hashses are even using more 80 bytes compared to MEMORY USAGE stating 65. I'm sure the rdb-tools is probably way out of date and not accurate, but I wonder if it truly is 65 bytes or something even less.
13:16:41 GMT <sembiance> hrm, seems like it might be pretty accurate for actual usage as doing an INFO and comparing used_memory before and after a `HINCRBY hz a 9223372036854775807` and a `DEL hz` shows almost the same difference. 73 bytes actual, whereas `MEMORY USAGE hz` reported 72 bytes
13:17:11 GMT <sembiance> err, that's backwards. 72 from used_memory and 73 from MEMORY USAGE
15:57:02 GMT <Circuitsoft> Is there a difference between an empty Sorted Set and a non-existent key?
15:57:23 GMT <minus> there's none
15:58:00 GMT <Circuitsoft> So, if I zremrangebyscore and it happens to remove all items in the set, then the set essentially disappears from the cache entirely?
15:58:08 GMT <minus> yup
15:58:15 GMT <minus> applies to everything
15:58:20 GMT <Circuitsoft> Perfect. Thank you.
15:58:48 GMT <waterdrop> If I'm using RDB with save 1800 50 and dump.rdb in the Redis dir as the dump file, does that mean that the dump file just gets rewritten every 1800 sec? (So it only keeps the last backup it made?)
16:19:07 GMT <dbilli> Hello
16:19:40 GMT <badboy_> hi
16:19:41 GMT <dbilli> i have a problem with hiredis python library. My multithreaded python program blocks in the HiredisParser.read_response()
16:19:48 GMT <*> badboy_  hides
16:20:14 GMT <dbilli> i used "winpdb" to get the stack trace  and the process is blocked
16:20:28 GMT <badboy_> using hiredis-py directly?
16:20:29 GMT <dbilli> on a recv()  on BLPOP
16:20:59 GMT <badboy_> well, that makes sense?
16:20:59 GMT <dbilli> useing hiredis  from "import redis"
16:21:06 GMT <dbilli> working on debian 8.6
16:21:15 GMT <badboy_> redis != hiredis
16:21:17 GMT <dbilli> python-hiredis 0.1.4
16:21:21 GMT <badboy_> ok
16:21:22 GMT <dbilli> python-redis                       2.10.1-1
16:21:26 GMT <badboy_> redis will use hiredis, yeah
16:21:27 GMT <dbilli> redis-server                       2:2.8.17-1+deb8u5
16:21:34 GMT <badboy_> but that blpop will block seems perfectly fine?
16:21:43 GMT <dbilli> The processi is blocked on:
16:21:44 GMT <dbilli> buffer = self._sock.recv(socket_read_size)
16:21:49 GMT <badboy_> you can't multiplex commands over a single connection if one of it is blocking
16:21:58 GMT <dbilli> no multiplexing
16:22:12 GMT <dbilli> the reading thread has it's prive connection object
16:22:17 GMT <dbilli> private
16:22:38 GMT <badboy_> the other thing remains: it is doing exactly what is intended if you send BLPOP
16:22:44 GMT <badboy_> BLPOP is a blocking command
16:22:46 GMT <dbilli> the debugger shows that  the "buffer"  variabile  contains b'\n'  from the previous loop
16:22:54 GMT <badboy_> so I don't understand what your problem here is?
16:23:08 GMT <badboy_> did you actually push to the list it is blocked on and see if it continues to work?
16:23:10 GMT <dbilli> there is data on in the "queuy"
16:23:24 GMT <dbilli> and the process do not recv() anything
16:23:30 GMT <dbilli> more precisely
16:23:56 GMT <dbilli> it reads some data (buffer contains b'\n') from the previous loop before block
16:24:26 GMT <dbilli> i wonder: is there any bug in the  SYM_CRLF    handling?
16:24:58 GMT <badboy_> SYM_CRLF?
16:25:55 GMT <dbilli> SYM_CRLF  in  connection.py   of the  redis.py code
16:26:25 GMT <dbilli> the read_response()  method loops and assemble the entire response
16:26:51 GMT <dbilli> it check for \r\n (SYM_CRLF) respose terminator
16:27:11 GMT <dbilli> but it seems read data contains only "\n"
16:27:12 GMT <dbilli> .
16:27:57 GMT <badboy_> I see
16:27:58 GMT <badboy_> it could?
16:28:04 GMT <badboy_> I'm not responsible for redis-py^^
16:59:31 GMT <Circuitsoft> Is there a way to update the score of an item in a sorted list, only if that item already exists?
17:08:17 GMT <badboy_> https://redis.io/commands/zadd
17:08:30 GMT <badboy_> especially the XX option
22:40:18 GMT <sembiance> well darn, `MEMORY DOCTOR` crashed. probably because I have very little free ram left heh