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 (firstname.lastname@example.org)
To make changes to your subscription: