Re: Let's make PostgreSQL multi-threaded
От | Konstantin Knizhnik |
---|---|
Тема | Re: Let's make PostgreSQL multi-threaded |
Дата | |
Msg-id | d61b6b69-31b0-e8c3-b44e-122543a4ddb3@garret.ru обсуждение исходный текст |
Ответ на | Re: Let's make PostgreSQL multi-threaded (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Let's make PostgreSQL multi-threaded
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: