From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, Jim(dot)Nasby(at)bluetreble(dot)com, craig(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Protect syscache from bloating with negative cache entries |
Date: | 2018-03-07 17:58:07 |
Message-ID: | 20180307175807.pvfeuhbrhhmewt3p@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-03-07 14:48:48 -0300, Alvaro Herrera wrote:
> Oh, I wasn't suggesting to throw away the whole cache at that point;
> only that that is a convenient to do whatever cleanup we want to do.
But why is that better than doing so continuously?
> What I'm not clear about is exactly what is the cleanup that we want to
> do at that point. You say it should be based on some configured size;
> Robert says any predefined size breaks [performance for] the case where
> the workload uses size+1, so let's use time instead (evict anything not
> used in more than X seconds?), but keeping in mind that a workload that
> requires X+1 would also break.
We mostly seem to have found that adding a *minimum* size before
starting evicting basedon time solves both of our concerns?
> So it seems we've arrived at the
> conclusion that the only possible solution is to let the user tell us
> what time/size to use. But that sucks, because the user doesn't know
> either (maybe they can measure, but how?), and they don't even know that
> this setting is there to be tweaked; and if there is a performance
> problem, how do they figure whether or not it can be fixed by fooling
> with this parameter? I mean, maybe it's set to 10 and we suggest "maybe
> 11 works better" but it turns out not to, so "maybe 12 works better"?
> How do you know when to stop increasing it?
I don't think it's that complicated, for the size figure. Having a knob
that controls how much memory a backend uses isn't a new concept, and
can definitely depend on the usecase.
> This seems a bit like max_fsm_pages, that is to say, a disaster that was
> only fixed by removing it.
I don't think that's a meaningful comparison. max_fms_pages had
persistent effect, couldn't be tuned without restarts, and the
performance dropoffs were much more "cliff" like.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Matheus de Oliveira | 2018-03-07 18:10:43 | Re: [PATCH] Add support for ON UPDATE/DELETE actions on ALTER CONSTRAINT |
Previous Message | Alvaro Herrera | 2018-03-07 17:48:48 | Re: Protect syscache from bloating with negative cache entries |