alternate approaches to warning about "millions of sequential scans" #1208

Upgraded from NC-34 to 35.0.1, now I see what is now a warning I cannot easily fix:

Some tables have many sequential scans and no index scans, suggesting a missing index.

2 table(s) have > 1M sequential scans without any index scans.

    oc_share
    oc_mimetypes

Some sleuthing suggests going into internal databases in order to squelch this, I think that's in general a bad idea.

Suggestions?

1. Count sequential scans over time, not just overall. My instances of NC are many years old, counting the number of scans over that period is a naive metric.
2. For those two tables (any others?), don't warn about it. Or call it a Note. But certainly not a Warning, otherwise I'll hit alarm-fatigue.

I've been using NC for years, but for newer users, less-tolerant users, and/or those who are less invested in NC in general, I suggest it isn't hard to imagine them migrating away due to untrusted warnings/alarms that cannot be easily dealt with.

I like warnings/alarms, I invest time periodically to assess the health of my servers. But alarm-fatigue is a real thing and I measure and value the admin time I need for each service. As it adds up, the "value" changes, and we are smart to reassess things. Please help improve the warning process, I don't think bullet 1 is onerous, and it'll go a long way to normalizing this type of problem (which can be quite real and impactful, I suspect).

Thanks!