Re: [HACKERS] Protect syscache from bloating with negative cache entries
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | CAB7nPqQABjAGDzTREuHOgJS3iHY6nVZ+Z2x1cL1JLKBLMpzXTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Protect syscache from bloating with negative cache entries (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Protect syscache from bloating with negative cache entries
|
Список | pgsql-hackers |
On Wed, Dec 21, 2016 at 5:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > If I thought that "every ten minutes" was an ideal way to manage this, > I might worry about that, but it doesn't really sound promising at all. > Every so many queries would likely work better, or better yet make it > self-adaptive depending on how much is in the local syscache. > > The bigger picture here though is that we used to have limits on syscache > size, and we got rid of them (commit 8b9bc234a, see also > https://www.postgresql.org/message-id/flat/5141.1150327541%40sss.pgh.pa.us) > not only because of the problem you mentioned about performance falling > off a cliff once the working-set size exceeded the arbitrary limit, but > also because enforcing the limit added significant overhead --- and did so > whether or not you got any benefit from it, ie even if the limit is never > reached. Maybe the present patch avoids imposing a pile of overhead in > situations where no pruning is needed, but it doesn't really look very > promising from that angle in a quick once-over. Have there been ever discussions about having catcache entries in a shared memory area? This does not sound much performance-wise, I am just wondering about the concept and I cannot find references to such discussions. -- Michael
В списке pgsql-hackers по дате отправления: