On 3/6/19 9:17 PM, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: >> 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. > > Yeah ... LRU maintenance was another thing that used to be in the > catcache logic and was thrown out as far too expensive. Your idea > of just using a clock sweep instead seems plausible. >
I agree clock sweep might be sufficient, although the benchmarks done in this thread so far do not suggest the LRU approach is very expensive. A simple true/false flag, as proposed by Robert, would mean we can only do the cleanup once per the catalog_cache_prune_min_age interval, so with the default value (5 minutes) the entries might be between 5 and 10 minutes old. That's probably acceptable, although for higher values the range gets wider and wider ... Which part of the LRU approach is supposedly expensive? Updating the lastaccess field or moving the entries to tail? I'd guess it's the latter, so perhaps we can keep some sort of age field, update it less frequently (once per minute?), and do the clock sweep? BTW wasn't one of the cases this thread aimed to improve a session that accesses a lot of objects in a short period of time? That balloons the syscache, and while this patch evicts the entries from memory, we never actually release the memory back (because AllocSet just moves it into the freelists) and it's unlikely to get swapped out (because other chunks on those memory pages are likely to be still used). I've proposed to address that by recreating the context if it gets too bloated, and I think Alvaro agreed with that. But I haven't seen any further discussion about that. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
