sp_Blitz: Add check for very high Query Store memory usage

[ReeceGoding]

Closes item 8 in #3527. Other items in that issue remain open.

I really didn't do anything smart while making this. I just cracked open the docs for sys.dm_os_memory_clerks and searched for references to Query Store.

1 GB was chosen utterly arbitrarily. I have no idea what can reasonably be considered a ridiculously high amount of Query Store memory usage. I've never seen a box crack 0.75 GB.

I've made this a priority 50 issue under the 'Performance' header. If your Query Store is eating a ridiculous amount of memory, then you have something interesting going on and ought to look. Everything with a number higher than 50 under the same header seemed far less important.

No useful URL has come to mind. Online research about Query Store overhead never mentions checking this metric, even though sys.dm_os_memory_clerks is the basis for a few of our checks. I could link to a generic guide on how to configure Query Store, but that wouldn't focus on the problem.

This is my first new check for sp_Blitz, so it's quite likely that it's missing something important. It's passed the limited suite of tests that I've tried on my local instance.

[BrentOzar]

The idea is interesting, but I did a quick check on the data from SQL ConstantCare, and there are indeed tons of boxes with >1GB of memory in Query Store, going as high as 18GB, for boxes that have 256GB+ memory.

I'm not saying 18GB is normal, but <10% of the box's memory doesn't seem like a big consumer. Because of that, in order to set a threshold, we should probably be able to answer these questions:

• What's the problem we're trying to solve?
• What's the evidence we have that the user is experiencing degraded performance because of this?
• What's the specific action we recommend users take to fix it?

I don't have those answers handy, so I don't think this is a good fit for sp_Blitz. If you do run into a box where you're running into specific, provable problems due to high memory consumption by Query Store, then let's have a conversation from there, but until then let's avoid adding general advice that may not actually fix a problem.