On Fri, Mar 1, 2019 at 3:33 AM Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > > It is artificial (or acutually wont't be repeatedly executed in a > > > session) but anyway what can get benefit from > > > catalog_cache_memory_target would be a kind of extreme. > > > > I agree. So then let's not have it. > > Ah... Yeah! I see. Andres' concern was that crucial syscache > entries might be blown away during a long idle time. If that > happens, it's enough to just turn off in the almost all of such > cases.
+1. > In the attached v18, > catalog_cache_memory_target is removed, > removed some leftover of removing the hard limit feature, > separated catcache clock update during a query into 0003. > attached 0004 (monitor part) in order just to see how it is working. > > v18-0001-Add-dlist_move_tail: > Just adds dlist_move_tail > > v18-0002-Remove-entries-that-haven-t-been-used-for-a-certain-: > Revised pruning feature. OK, so this is getting simpler, but I'm wondering why we need dlist_move_tail() at all. It is a well-known fact that maintaining LRU ordering is expensive and it seems to be unnecessary for our purposes here. Can't CatCacheCleanupOldEntries just use a single-bit flag on the entry? If the flag is set, clear it. If the flag is clear, drop the entry. When an entry is used, set the flag. Then, entries will go away if they are not used between consecutive calls to CatCacheCleanupOldEntries. Sure, that might be slightly less accurate in terms of which entries get thrown away, but I bet it makes no real difference. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
