On 2017-12-01 17:03:28 -0500, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2017-12-01 16:40:23 -0500, Tom Lane wrote:
> >> I have no faith in either of these proposals, because they both assume
> >> that the problem only arises over the course of many minutes. In the
> >> recent complaint about pg_dump causing relcache bloat, it probably does
> >> not take nearly that long for the bloat to occur.
>
> > To me that's a bit of a different problem than what I was discussing
> > here. It also actually doesn't seem that hard - if your caches are
> > growing fast, you'll continually get hash-resizing of the
> > various. Adding cache-pruning to the resizing code doesn't seem hard,
> > and wouldn't add meaningful overhead.
>
> That's an interesting way to think about it, as well, though I'm not
> sure it's quite that simple. If you tie this to cache resizing then
> the cache will have to grow up to the newly increased size before
> you'll prune it again. That doesn't sound like it will lead to nice
> steady-state behavior.
Yea, it's not perfect - but if we do pruning both at resize *and* on
regular intervals, like once-a-minute as I was suggesting, I don't think
it's that bad. The steady state won't be reached within seconds, true,
but the negative consequences of only attempting to shrink the cache
upon resizing when the cache size is growing fast anyway doesn't seem
that large.
I don't think we need to be super accurate here, there just needs to be
*some* backpressure.
I've had cases in the past where just occasionally blasting the cache
away would've been good enough.
Greetings,
Andres Freund
