On 17/09/2020 15:06, Tom Lane wrote:
=?UTF-8?Q?=C3=98ystein_Kolsrud?= 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
cac
On Thu, Sep 17, 2020 at 7:27 PM Peter J. Holzer wrote:
> What I would do:
>
> * Set log_statement to all (warning: that can be a lot of log messages.
> It can also be a privacy/security hazard, depending on who has access
> to the server and how sensitive queries are).
> * Frequently (at lea
On Thu, Sep 17, 2020 at 10:06:07AM -0400, Tom Lane wrote:
> =?UTF-8?Q?=C3=98ystein_Kolsrud?= 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 consumpt
On 2020-09-17 11:19:07 +0200, Øystein Kolsrud wrote:
> I have a product that uses PostgreSQL (v9.6) as database on Windows, and we
> often observe that the "shared working set" memory reported for the individual
> connection processes is quite high (around 200MB), but the "private working
> set" is
=?UTF-8?Q?=C3=98ystein_Kolsrud?= 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
Øystein Kolsrud schrieb am 17.09.2020 um 11:19:
All settings typically referred to (like "work_mem" and
"temp_buffers") are at default settings, and I have a very hard time
seeing how those settings could add up to memory in the magnitude of
200MB. The "max_connections" settings is quite high (>1
