The problem/use-case that the feature addresses
This is an enhancement for INFO command, previously INFO only support one argument for different info section , if user want to get more categories information, either perform INFO all/default or calling INFO for multiple times.
Description of the feature
I am working on this feature and want some feedback form the community before proceeding. The goal of adding this feature is to let the user retreive multiple categories via the INFO command. The approach I am using is to have a list subcommands which are in "default", "all" and "everything" arguments for INFO, for example INFO default has ["server", "clients", "memory", ... ].
If someone executes "INFO default commandstats" then default commands and info stats is printed.
A set is used which contains the commands to avoid duplication and if the set already contains default or all then commands such as server and clients is not added to the set because default already contains these commands.
Finally genRedisInfoString is used to get the sectionInfo for these commands which are then returned.
A use case for this is like Redis Sentinel, which periodically calling INFO command to refresh info from monitored Master/Slaves, only Server and Replication part categories are used for parsing information. If the INFO command can return just enough categories that client side needs, it can save a lot of time for client side parsing it as well as network bandwidth.
Any feedback is welcome about the approach and possible limitations or improvements so we can have an agreement on the feature before merging it to unstable.
Comment From: hwware
Hey @oranagra @yossigo, any feedback that you guys may have for this proposed approach? Thanks you
Comment From: oranagra
missed this... so this is a new design for #6891? (maybe it would have been better to respond there to continue the discussion).
so you'll build a set (dict?) of requested sections, and then each section in genRedisInfoString will attempt to look itself up in the set? that sounds like a good approach to me. :+1:
Side note: we don't call the sections in the INFO command "sub-commands".
Comment From: hwware
Yes this is a new design for https://github.com/redis/redis/pull/6891. I'll link this to the PR. Thanks.