You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just wanted to suggest to add the TYPE filter as a feature in redis commander for the initial SCAN (in case USE_SCAN is set) in addition to MATCH (which uses ROOT_PATTERN).
For me this would be really nice, because I am having 100k similar string keys, but I am actually mostly interested in just 5 lists or so. If there was a negative filter (or regex) for MATCH, I could use that, but unfortunately that's not possible. The 100k strings cause a lot of load locally for some reason.
In case adding the TYPE parameter is something you would be interested in, I could also do a PR. Maybe call it ROOT_TYPE?
The text was updated successfully, but these errors were encountered:
in "default.json" an empty pattern config entry should be provides to not change default behaviour
ROOT_TYPE seems resonable compared to existing env vars (defined in "custom-environment-variables.json")
using "keys" instead of "scan" the parameter is ignored. Maybe a warning on startup that type is set without using scan might be helpful. But this should not be printed on every scan run.
Hi,
I just wanted to suggest to add the TYPE filter as a feature in redis commander for the initial SCAN (in case USE_SCAN is set) in addition to MATCH (which uses ROOT_PATTERN).
For me this would be really nice, because I am having 100k similar string keys, but I am actually mostly interested in just 5 lists or so. If there was a negative filter (or regex) for MATCH, I could use that, but unfortunately that's not possible. The 100k strings cause a lot of load locally for some reason.
In case adding the TYPE parameter is something you would be interested in, I could also do a PR. Maybe call it ROOT_TYPE?
The text was updated successfully, but these errors were encountered: