On Fri, Mar 1, 2019 at 3:33 AM Kyotaro HORIGUCHI
<horiguchi.kyotaro@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