> > 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)
