Michael Paquier <michael.paqu...@gmail.com> writes: > ... There are even some apps that do not use pgbouncer, but drop > sessions after a timeout of inactivity to avoid a memory bloat because > of the problem of this thread.
Yeah, a certain company I used to work for had to do that, though their problem had more to do with bloat in plpgsql's compiled-functions cache (and ensuing bloat in the plancache), I believe. Still, I'm pretty suspicious of anything that will add overhead to catcache lookups. If you think the performance of those is not absolutely critical, turning off the caches via -DCLOBBER_CACHE_ALWAYS will soon disabuse you of the error. I'm inclined to think that a more profitable direction to look in is finding a way to limit the cache size. I know we got rid of exactly that years ago, but the problems with it were (a) the mechanism was itself pretty expensive --- a global-to-all-caches LRU list IIRC, and (b) there wasn't a way to tune the limit. Possibly somebody can think of some cheaper, perhaps less precise way of aging out old entries. As for (b), this is the sort of problem we made GUCs for. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers