X-Git-Url: https://git.saurik.com/redis.git/blobdiff_plain/0c9ca0e11ca290392e2747596b89d18db175af7e..1576520cc0c2deda30288bea797fdacf322581ec:/TODO?ds=inline diff --git a/TODO b/TODO index 00885d17..145ec524 100644 --- a/TODO +++ b/TODO @@ -1,9 +1,45 @@ -- Protocol changes as discussed in the Redis group -- keys expire -- sunion ssub -- write integers in a special way on disk (and on memory?) -- compact types for disk storing of short strings (no 4 bytes overhead!) -- network layer stresser in test in demo -- maxclients directive -- check 'server.dirty' everywere -- replication automated tests +Redis TODO +---------- + +WARNING: are you a possible Redis contributor? + Before implementing what is listed in this file + please drop a message in the Redis google group or chat with + antirez or pietern on irc.freenode.org #redis to check if the work + is already in progress and if the feature is still interesting for + us, and *how* exactly this can be implemented to have good changes + of a merge. Otherwise it is probably wasted work! Thank you + + +CLUSTER +======= + +* Implement rehashing and cluster check in redis-trib. +* Reimplement MIGRATE / RESTORE to use just in memory buffers (no disk at + all). This will require touching a lot of the RDB stuff around, but we may + hand with faster persistence for RDB. +* Implement the slave nodes semantics and election. +* Allow redis-trib to create a cluster-wide snapshot (using SYNC). +* Allow redis-trib to restore a cluster-wide snapshot (implement UPLOAD?). + +SCRIPTING +========= + +* SCRIPT FLUSH or alike to start a fresh interpreter? + +OPTIMIZATIONS +============= + +* SORT: Don't copy the list into a vector when BY argument is constant. +* Write the hash table size of every db in the dump, so that Redis can resize the hash table just one time when loading a big DB. +* Read-only mode for slaves. +* Redis big lists as linked lists of small ziplists? + Possibly a simple heuristic that join near nodes when some node gets smaller than the low_level, and split it into two if gets bigger than high_level. + +KNOWN BUGS +========== + +* #519: Slave may have expired keys that were never read in the master (so a DEL + is not sent in the replication channel) but are already expired since + a lot of time. Maybe after a given delay that is undoubtably greater than + the replication link latency we should expire this key on the slave on + access?