Typically, in a Grafana dashboard you will see a bunch of queries related to one app so label matchers typically overlap. This is especially the case with variables such as env or app. So, if, let's say, env is a high cardinality label then opening a Grafana dashboard with 10 panels that have ...{env="prod"} will load postings for env="prod" 10 times if we are unlucky.
Describe the solution you'd like
If there is more than one call to expand env="prod" postings for some block then the others should wait until the other finishes. If the previous request times out or errors out then we should try doing this again.
Describe alternatives you've considered
Groupcache kind of handles this for us natively but it would be cool to have such mechanism in general enabled by default locally.
I think you attempted the same issue before? @GiedriusS
Do you think the expanded posting cache helps here? I think it doesn't address the issue but should help a little bit here
Is your proposal related to a problem?
Typically, in a Grafana dashboard you will see a bunch of queries related to one app so label matchers typically overlap. This is especially the case with variables such as
env
orapp
. So, if, let's say,env
is a high cardinality label then opening a Grafana dashboard with 10 panels that have...{env="prod"}
will load postings forenv="prod"
10 times if we are unlucky.Describe the solution you'd like
If there is more than one call to expand
env="prod"
postings for some block then the others should wait until the other finishes. If the previous request times out or errors out then we should try doing this again.Describe alternatives you've considered
Groupcache kind of handles this for us natively but it would be cool to have such mechanism in general enabled by default locally.
Additional context
N/A