On Tue, Feb 12, 2019 at 02:53:40AM +0100, Tomas Vondra wrote: > Right. But the logic behind time-based approach is that evicting such > entries should not cause any issues exactly because they are accessed > infrequently. It might incur some latency when we need them for the > first time after the eviction, but IMHO that's acceptable (although I > see Andres did not like that). > > FWIW we might even evict entries after some time passes since inserting > them into the cache - that's what memcached et al do, IIRC. The logic is > that frequently accessed entries will get immediately loaded back (thus > keeping cache hit ratio high). But there are reasons why the other dbs > do that - like not having any cache invalidation (unlike us).
Agreed. If this fixes 90% of the issues people will have, and it applies to the 99.9% of users who will never tune this, it is a clear win. If we want to add something that requires tuning later, we can consider it once the non-tuning solution is done. > That being said, having a "minimal size" threshold before starting with > the time-based eviction may be a good idea. Agreed. I see the minimal size as a way to keep the systems tables in cache, which we know we will need for the next query. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +