Re: [HACKERS] Protect syscache from bloating with negative cache entries
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Protect syscache from bloating with negative cache entries |
Дата | |
Msg-id | CAB7nPqTgYCfy+-q_aQanLjGnY0zDWdFuMw3Cw8AJjJb3hEca=w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Protect syscache from bloating with negative cacheentries (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
On Sat, Jan 14, 2017 at 9:36 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > On 01/14/2017 12:06 AM, Andres Freund wrote: >> On 2017-01-13 17:58:41 -0500, Tom Lane wrote: >>> >>> But, again, the catcache isn't the only source of per-process bloat >>> and I'm not even sure it's the main one. A more holistic approach >>> might be called for. >> >> It'd be helpful if we'd find a way to make it easy to get statistics >> about the size of various caches in production systems. Right now >> that's kinda hard, resulting in us having to make a lot of >> guesses... > > What about a simple C extension, that could inspect those caches? Assuming > it could be loaded into a single backend, that should be relatively > acceptable way (compared to loading it to all backends using > shared_preload_libraries). This extension could do a small amount of work on a portion of the syscache entries at each query loop, still I am wondering if that would not be nicer to get that in-core and configurable, which is basically the approach proposed by Horiguchi-san. At least it seems to me that it has some merit, and if we could make that behavior switchable, disabled by default, that would be a win for some class of applications. What do others think? -- Michael
В списке pgsql-hackers по дате отправления: