From: Tomas Vondra
> I don't think we need to remove the expired entries right away, if
there
> are only very few of them. The cleanup requires walking the hash
table,
> which means significant fixed cost. So if there are only few expired
> entries (say, less than 25% of the cache), we can just leave them
around
> and clean them if we happen to stumble on them (although that may
not be
> possible with dynahash, which has no concept of expiration) of
before
> enlarging the hash table.
I agree in that we don't need to evict cache entries as long as the
memory permits (within the control of the DBA.)
But how does the concept of expiration fit the catcache? How would
the user determine the expiration time, i.e. setting of
syscache_prune_min_age? If you set a small value to evict unnecessary
entries faster, necessary entries will also be evicted. Some access
counter would keep accessed entries longer, but some idle time (e.g.
lunch break) can flush entries that you want to access after the lunch
break.
The idea of expiration applies to the case where we want possibly
stale entries to vanish and load newer data upon the next access. For
example, the TTL (time-to-live) of Memcached, Redis, DNS, ARP. Is the
catcache based on the same idea with them? No.
What we want to do is to evict never or infrequently used cache
entries. That's naturally the task of LRU, isn't it? Even the high
performance Memcached and Redis uses LRU when the cache is full. As
Bruce said, we don't have to be worried about the lock contention or
something, because we're talking about the backend local cache. Are
we worried about the overhead of manipulating the LRU chain? The
current catcache already does it on every access; it calls
dlist_move_head() to put the accessed entry to the front of the hash
bucket.
> So if we want to address this case too (and we probably want), we
may
> need to discard the old cache memory context someho (e.g. rebuild
the
> cache in a new one, and copy the non-expired entries). Which is a
nice
> opportunity to do the "full" cleanup, of course.
The straightforward, natural, and familiar way is to limit the cache
size, which I mentioned in some previous mail. We should give the DBA
the ability to control memory usage, rather than considering what to
do after leaving the memory area grow unnecessarily too large. That's
what a typical "cache" is, isn't it?
https://en.wikipedia.org/wiki/Cache_(computing)
"To be cost-effective and to enable efficient use of data, caches must
be relatively small."
Another relevant suboptimal idea would be to provide each catcache
with a separate memory context, which is the child of
CacheMemoryContext. This gives slight optimization by using the slab
context (slab.c) for a catcache with fixed-sized tuples. But that'd
be a bit complex, I'm afraid for PG 12.
Regards
MauMau
