On Mon, Aug 28, 2017 at 5:24 AM, Kyotaro HORIGUCHI
<horiguchi.kyotaro@lab.ntt.co.jp> wrote:
> This patch have had interferences from several commits after the
> last submission. I amended this patch to follow them (up to
> f97c55c), removed an unnecessary branch and edited some comments.
I think the core problem for this patch is that there's no consensus
on what approach to take. Until that somehow gets sorted out, I think
this isn't going to make any progress. Unfortunately, I don't have a
clear idea what sort of solution everybody could tolerate.
I still think that some kind of slow-expire behavior -- like a clock
hand that hits each backend every 10 minutes and expires entries not
used since the last hit -- is actually pretty sensible. It ensures
that idle or long-running backends don't accumulate infinite bloat
while still allowing the cache to grow large enough for good
performance when all entries are being regularly used. But Tom
doesn't like it. Other approaches were also discussed; none of them
seem like an obvious slam-dunk.
Turning to the patch itself, I don't know how we decide whether the
patch is worth it. Scanning the whole (potentially large) cache to
remove negative entries has a cost, mostly in CPU cycles; keeping
those negative entries around for a long time also has a cost, mostly
in memory. I don't know how to decide whether these patches will help
more people than it hurts, or the other way around -- and it's not
clear that anyone else has a good idea about that either.
Typos: funciton, paritial.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company