On Thu, Nov 30, 2017 at 11:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Nov 29, 2017 at 11:17 PM, Tom Lane <tgl@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