On Thu, Mar 7, 2019 at 11:40 PM Ideriha, Takeshi
<ideriha.takeshi@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
