Re: PostgreSQL processes use large amount of private memory on Windows

From: Chris Sterritt <chris(dot)sterritt(at)yobota(dot)xyz>
To: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL processes use large amount of private memory on Windows
Date: 2020-10-12 13:35:41
Message-ID: 64bdfa38-49e3-1ae7-7909-6fab7af1e0d1@yobota.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


On 17/09/2020 15:06, Tom Lane wrote:
> =?UTF-8?Q?=C3=98ystein_Kolsrud?= <kolsrud(at)gmail(dot)com> writes:
>> So my question is: When does a postgres process forked for a connection use
>> private memory instead of shared, and what can I do to avoid this?
> The only significant long-term consumption of private memory is for
> caches. There are catalog caches, which can get large if the session
> accesses a whole lot of database objects (e.g., thousands of different
> tables). Some of the PLs maintain caches with parsed versions of any
> function that's been executed. (An ex-employer of mine had a lot of
> trouble in that regard, because they had hundreds of thousands of lines
> worth of plpgsql functions.) There isn't any user-accessible knob for
> limiting the size of those caches. If you have a problem of that sort,
> about the only way to mitigate it is to use fewer backends so that the
> total memory consumption stays in bounds, or redesign your application.
> In some cases it might help to restart your sessions when they get too
> big, but that seems like at best a band-aid.
>
> regards, tom lane
>
>
Would executing DISCARD ALL release the PL cache?

Regards, Chris Sterritt

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Peter J. Holzer 2020-10-12 14:10:08 Column aliases in GROUP BY and HAVING
Previous Message Peter Eisentraut 2020-10-12 06:33:30 Call for translations