On Thu, Feb 14, 2019 at 01:31:49AM +0000, Tsunakawa, Takayuki wrote: > From: Bruce Momjian [mailto:br...@momjian.us] > > > That being said, having a "minimal size" threshold before starting > > > with the time-based eviction may be a good idea. > > > > Agreed. I see the minimal size as a way to keep the systems tables > > in cache, which we know we will need for the next query. > > Isn't it the maximum size, not minimal size? Maximum size allows > to keep desired amount of system tables in memory as well as to > control memory consumption to avoid out-of-memory errors (OS crash!). > I'm wondering why people want to take a different approach to > catcatch, which is unlike other PostgreSQL memory e.g. shared_buffers, > temp_buffers, SLRU buffers, work_mem, and other DBMSs.
Well, that is an _excellent_ question, and one I had to think about. I think, in general, smaller is better, as long as making something smaller doesn't remove data that is frequently accessed. Having a timer to expire only old entries seems like it accomplished this goal. Having a minimum size and not taking it to zero size makes sense if we know we will need certain entries like pg_class in the next query. However, if the session is idle for hours, we should just probably remove everything, so maybe the minimum doesn't make sense --- just remove everything. As for why we don't do this with everything --- we can't do it with shared_buffers since we can't change its size while the server is running. For work_mem, we assume all the work_mem data is for the current query, and therefore frequently accessed. Also, work_mem is not memory we can just free if it is not used since it contains intermediate results required by the current query. I think temp_buffers, since it can be resized in the session, actually could use a similar minimizing feature, though that would mean it behaves slightly differently from shared_buffers, and it might not be worth it. Also, I assume the value of temp_buffers was mostly for use by the current query --- yes, it can be used for cross-query caching, but I am not sure if that is its primary purpose. I thought its goal was to prevent shared_buffers from being populated with temporary per-session buffers. I don't think other DBMSs are a good model since they have a reputation for requiring a lot of tuning --- tuning that we have often automated. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +