On Thu, Nov 30, 2017 at 11:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> The thing that makes me uncomfortable about this is that we used to have a >>> catcache size limitation mechanism, and ripped it out because it had too >>> much overhead (see commit 8b9bc234a). I'm not sure how we can avoid that >>> problem within a fresh implementation. > >> At the risk of beating a dead horse, I still think that the amount of >> wall clock time that has elapsed since an entry was last accessed is >> very relevant. > > While I don't object to that statement, I'm not sure how it helps us > here. If we couldn't afford DLMoveToFront(), doing a gettimeofday() > during each syscache access is surely right out.
Well, yeah, that would be insane. But I think even something very rough could work well enough. I think our goal should be to eliminate cache entries that are have gone unused for many *minutes*, and there's no urgency about getting it to any sort of exact value. For non-idle backends, using the most recent statement start time as a proxy would probably be plenty good enough. Idle backends might need a bit more thought. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
