On Mon, Aug 28, 2017 at 5:24 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
