Currently, when the in-memory sql stats store is full, it will attempt to flush the in-memory stats into the system table. During that time, all stats for new fingerprint IDs will be discarded.

If the system table is down (for various different reasons) for the flush, then we will not be able to record any new statistics since the sql stats flush will entering into crash loop. In this case, current sql stats behaviour means we will not able to record any new statistics with new fingerperintID.

We want a better eviction strategy to better handle the failure scenarios. A good starting point is the last paragraph in the future work section in the original RFC.

Jira issue: CRDB-9537