Closed simonhatch closed 6 years ago
As far as I can tell, this doesn't need to be indexed. We don't query on it in any way. There's also a reference to it in index.yaml, the comment being it's needed for a projection query but there are no projection queries that match this (maybe long gone?).
Feels like this is safe to switch to indexed=False, and remove the reference in index.yaml, wdyt?
@eakuefner @anniesullie
Note that you need to vacuum indexes to actually make any change on the dashboard, so removing from index.yaml is totally safe even if they are used.
I think the big problem with vacuuming any given index is that if we're somehow using it, any query that uses it will not work until they're re-indexed, which could take a full day. That said, if you're confident that you could fix any issue which arises (i.e. by removing projection from the query that broke) I'm all for vacuuming.
The scariest part of vacuuming is that if index.yaml is somehow not up to date, any index we're relying on which has been removed from it will be removed and queries using it won't work until it re-indexes, which could take multiple days for Row entities. But the cost of these indexes is quite high, so I am still all for solving this problem.
I think description and overridden_anomaly_config can also have indexing removed.
@benshayden since we're talking indexes in another bug as well
Was looking these over, maybe we want to check some of these like monitored to see if they need to be indexed?