On Thu, Mar 7, 2019 at 11:40 PM Ideriha, Takeshi <ideriha.take...@jp.fujitsu.com> wrote: > Just to be sure, we introduced the LRU list in this thread to find the > entries less than threshold time > without scanning the whole hash table. If hash table becomes large without > LRU list, scanning time becomes slow.
Hmm. So, it's a trade-off, right? One option is to have an LRU list, which imposes a small overhead on every syscache or catcache operation to maintain the LRU ordering. The other option is to have no LRU list, which imposes a larger overhead every time we clean up the syscaches. My bias is toward thinking that the latter is better, because: 1. Not everybody is going to use this feature, and 2. Syscache cleanup should be something that only happens every so many minutes, and probably while the backend is otherwise idle, whereas lookups can happen many times per millisecond. However, perhaps someone will provide some evidence that casts a different light on the situation. I don't see much point in continuing to review this patch at this point. There's been no new version of the patch in 3 weeks, and there is -- in my view at least -- a rather frustrating lack of evidence that the complexity this patch introduces is actually beneficial. No matter how many people +1 the idea of making this more complicated, it can't be justified unless you can provide a test result showing that the additional complexity solves a problem that does not get solved without that complexity. And even then, who is going to commit a patch that uses a design which Tom Lane says was tried before and stunk? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
