Re: Improve pg_stat_statements scalability

> > Now, as far as eviction goes. I have spent time with the help of
> > my benchmarking suite [1] looking into various strategies. My main
> > finding is that performing parallel evictions as discussed and
> > proposed in v3 will not work. In the high churn case, we will
> > not be able to put enough back pressure to keep the growth
> > of the dshash in check.
> >
> > So, the idea that I have now is what I am attaching in 0004.
> >
> > The important design points are:
> >
> > 1. We need to hard-cap growth of the dshash, so we cannot avoid
> > skipping new entries if we hit the cap. Right now the hard-cap
> > is pgss_max * 2.
> >
> > 2. We need to give new entries time to live before they become
> > eviction candidates. This helps in low-churn-but-some-churn cases.
> >
> > 3. Least-recently-used will be the eviction strategy, with a
> > threshold to keep new entries alive long enough to build up
> > their popularity before becoming candidates.

One subtle but important point is that eviction decisions are
driven by a new atomic counter that tracks live entries, which
is incremented when a new entry is created and decremented when
and an entry is dropped by eviction. This is a counter that
pg_stat_statements defines. The reason being is the core
pgstat_get_entry_count() is the number of entries in the dshash,
which also includes dropped-but-still-referenced by other backend
entries. So this core counter cannot be used to drive when an eviction
occurs, but it's used to set a hard cap on the growth of the dshash.

--
Sami Imseih
Amazon Web Services (AWS)