Add metrics for subscription queries

[drogus]

Description of Changes

We have some metrics measuring various lower level things like index scans, but at the moment we have no easy way to figure out which columns might need an index. This commit introduces three new metrics that provide that information by labeling count, latency, and number of rows canned along with the scan type (index scan, table scan, mixed scan) and info about unindexed columns.

API and ABI breaking changes

None

Expected complexity level and risk

2

I'm honestly not sure. I don't think it's overly complex, but it adds some overhead in the subscriptions initial query path.

Testing

• I've tested the changes locally

[joshua-spacetime]

If the goal is to be able to identify columns that should be indexed, the only operation you care about is full table scan -> filter. It's unclear to me what the purpose of all of the different scan strategies is, and how they're actionable.

[drogus]

@joshua-spacetime I guess I wanted to add scan type in case we want to use these metrics for something else, but couldn't a partial index scan also benefit from adding a compound index? Like, you have x, y columns, but you have an index only on x, but for each x value you have 10k rows with different y values. So then SELECT * FROM points WHERE x = 10 AND y = 10 would use an index on the x column, but then it would have to load 10k rows and filter them. Am I missing something?

[joshua-spacetime]

Approved with a small comment.

Also, right now these metrics are not recorded for (add|remove)_single_subscription. I don't believe these methods are invoked from the sdk at all, so it's probably fine. I just wanted to make sure this was what you intended.

As far as performance goes, I don't see any problem adding these metrics. It's just a small amount of overhead added to an initial subscribe. And in terms of prometheus, we already have table-level metrics, so it won't explode cardinality.