On 13.06.2023 11:46 AM, Kyotaro Horiguchi wrote:
So we can assume that catalog and relation cache should always fit in
memory
memory (otherwise significant rewriting of all Postgtres code working
with relations will be needed).
I'm not sure that is ture.. But likely to be?
Sorry, looks like I was wrong.
Right now access to sys/cat/rel caches is protected by reference counter.
So we can easily add some replacement algorithm for this caches.
I don't think it is efficient that PostgreSQL to consume a large
amount of memory for seldom-used content. While we may not need
expiration mechanism for moderate use cases, I have observed instances
where a single process hogs a significant amount of memory,
particularly for intermittent tasks.
Usually system catalog is small enough and do not cause any problems
with memory consumption.
But partitioned and temporary tables can cause bloat of catalog.
In such cases some eviction mechanism will be really useful.
But I do not think that it is somehow related with using threads instead
of process.
The question whether to use private or shared cache is not directly
related to threads vs. process choice.
Yes, threads makes implementation of shared cache much easier. But it
can be also done using dynamic
memory segments, Definitely shared cache has its pros and cons, first if
all it requires sycnhronization
which may have negative impact o performance.
I have made an attempt to combine both caches: use relatively small
per-backend local cache
and large shared cache.
I wonder what people think about the idea to make backends less thick by
using shared cache.
