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