On Mon, Feb 25, 2019 at 1:27 AM Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > I'd like to see some evidence that catalog_cache_memory_target has any > > value, vs. just always setting it to zero. > > It is artificial (or acutually wont't be repeatedly executed in a > session) but anyway what can get benefit from > catalog_cache_memory_target would be a kind of extreme.
I agree. So then let's not have it. We shouldn't add more mechanism here than actually has value. It seems pretty clear that keeping cache entries that go unused for long periods can't be that important; even if we need them again eventually, reloading them every 5 or 10 minutes can't hurt that much. On the other hand, I think it's also pretty clear that evicting cache entries that are being used frequently will have disastrous effects on performance; as I noted in the other email I just sent, consider the effects of CLOBBER_CACHE_ALWAYS. No reasonable user is going to want to incur a massive slowdown to save a little bit of memory. I see that *in theory* there is a value to catalog_cache_memory_target, because *maybe* there is a workload where tuning that GUC will lead to better performance at lower memory usage than any competing proposal. But unless we can actually see an example of such a workload, which so far I don't, we're adding a knob that everybody has to think about how to tune when in fact we have no idea how to tune it or whether it even needs to be tuned. That doesn't make sense. We have to be able to document the parameters we have and explain to users how they should be used. And as far as this parameter is concerned I think we are not at that point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
