Re: Protect syscache from bloating with negative cache entries

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, David Steele <david(at)pgmasters(dot)net>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Protect syscache from bloating with negative cache entries
Date: 2018-03-01 19:29:18
Message-ID: 20180301192918.cqh3hoo4746lqf4i@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2018-03-01 14:24:56 -0500, Robert Haas wrote:
> On Thu, Mar 1, 2018 at 1:54 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > So this is hardcoded, without any sort of cache pressure logic? Doesn't
> > that mean we'll often *severely* degrade performance if a backend is
> > idle for a while?
>
> Well, it is true that if we flush cache entries that haven't been used
> in a long time, a backend that is idle for a long time might be a bit
> slow when (and if) it eventually becomes non-idle, because it may have
> to reload some of those flushed entries.

Right. Which might be very painful latency wise. And with poolers it's
pretty easy to get into situations like that, without the app
influencing it.

> On the other hand, a backend that holds onto a large number of cache
> entries that it's not using for tens of minutes at a time degrades the
> performance of the whole system unless, of course, you're running on a
> machine that is under no memory pressure at all.

But it's *extremely* common to have no memory pressure these days. The
inverse definitely also exists.

> I don't understand why people keep acting as if holding onto cache
> entries regardless of how infrequently they're being used is an
> unalloyed good.

Huh? I'm definitely not arguing for that? I think we want a feature like
this, I just don't think the logic when to prune is quite sophisticated
enough?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2018-03-01 19:31:08 Re: [GSOC 18] Performance Farm Project
Previous Message Robert Haas 2018-03-01 19:24:56 Re: Protect syscache from bloating with negative cache entries