02:39:20 GMT <reaper> ?
06:20:11 GMT <sagax> how to save selected database to dump file?
07:26:21 GMT <minus> sagax: you can only save all databases to dump.rdb afaik
07:31:53 GMT <mstaack> sagax: this node tool allows to export single db..so it must be possible somehow i guess: https://github.com/jeremyfa/node-redis-dump
07:37:49 GMT <minus> well, that too connects to redis and pulls the data; it doesn't use rdbs
07:38:07 GMT <minus> of course there's tools that parse rdbs and possibly can extract a single database
07:38:53 GMT <minus> cheapest way is probably to fire up a new redis instance, slaveof it, de-slaveof it, wipe other databases and then write a dump
07:39:07 GMT <minus> assuming all databases are reasonably sized
07:39:15 GMT <minus> ^ sagax
07:39:49 GMT <sagax> oh, thanks!
07:40:05 GMT <sagax> it's help me
08:00:48 GMT <baurmatt> Good morning, just a quick question regarding the maxclients setting. Is there something like an overhead per client connection (e.g. 1 connection == ~0,5MB RAM)? Just trying to figure out a good default setting for our setups which won't harm the server/redis
08:21:12 GMT <ankit_> I want to expire some keys and get back the data for those keys at expiry. I got a similar question on SO: http://stackoverflow.com/questions/11810020/how-to-handle-session-expire-basing-redis/11815594#11815594
08:21:21 GMT <ankit_> For the solution 2 in the accepted answer
08:21:40 GMT <ankit_> I want to know why we are using MULTI/EXEC?
08:32:40 GMT <minus> seems unnecessary
11:11:14 GMT <jk34> > set val 1
11:11:20 GMT <jk34> > bitcount val
11:11:26 GMT <jk34> (integer) 3
11:11:34 GMT <jk34> why 3, not 1?
11:16:58 GMT <badboy_> Because the string "1" is the decimal 49 is the binary 110001
11:17:03 GMT <badboy_> jk34:
11:17:30 GMT <badboy_> Redis (more or less) only knows binary blobs
11:18:11 GMT <jk34> badboy_: thanks
11:37:26 GMT <jk34> so, every time I call "> incr val 1", the `val` is converted to long long from string (string2ll) and then back to string
11:37:39 GMT <jk34> seems inefficient
11:44:10 GMT <badboy_> actually, internally it is stored as an integer, so it only does a simple +1 addition on that value and than converts that back to a string
11:44:16 GMT <badboy_> so only half as inefficent
11:44:32 GMT <badboy_> I never seen _that_ being the bottleneck though
11:58:23 GMT <jk34> badboy_: thanks, got it
16:11:05 GMT <Mark__> afternoon all