https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6942
--- Comment #22 from Mark Martinec <[email protected]> --- > I wonder how many people are using Redis.pm.. > http://msgpack.org/ looks like a no-brainer to use with lua instead of our > own packing. For our little purpose of serializing two integers we don't need a cannon like JSON or msgpack, and lua. > But yes this requires db version bump if we want to go the polite way.. Yes, that's my concern too. Debian wheezy is still at 2.4, similarly our friends next door on Centos. > APPEND key value > Sounds slightly awkward. Also it would probably eat a lot more memory. Compared to the amount of storage needed to represent a key, its expiration, a pointer to a string, with its length stored as a 32-bit integer, a dozen or two more characters would make little difference. But this brings up another idea - knowing that small hashes are stored in redis in a very compact form - watch this surprise: my $r = Redis->new(encoding => undef); $r->flushall; my $info0 = $r->info; for (@rkeys) { $r->setex($_, 3024000, "ab"); } my $info1 = $r->info; printf("mem: %.1f bytes/key\n", ($info1->{used_memory} - $info0->{used_memory}) / @rkeys); $r->flushall; So with: $r->setex($_, 3024000, "ab"); we get: mem: 162.2 bytes/key Replacing $r->setex($_, 3024000, "ab"); by the 8-byte string (our representation of values above 255): $r->setex($_, 3024000, "abcdefgh"); mem: 170.2 bytes/key but see the following: $r->hset($_, "h", 9000); $r->hset($_, "s", 200000); $r->expire($_, 3024000); mem: 133.1 bytes/key !!! Not worth the trouble of packing/unpacking at all, and we can use atomic incrementing directly: $r->hincrby($_, "h", $nham); $r->hincrby($_, "s", $nspam); -- You are receiving this mail because: You are the assignee for the bug.
