From: | reid(dot)thompson(at)crunchydata(dot)com |
---|---|
To: | Roberto Mello <roberto(dot)mello(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [DOC] Add detail regarding resource consumption wrt max_connections |
Date: | 2024-01-22 13:58:23 |
Message-ID: | 2c9d3664ff7adc506191f92db031543925abe0df.camel@crunchydata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, 2024-01-19 at 17:37 -0500, reid(dot)thompson(at)crunchydata(dot)com wrote:
> On Sat, 2024-01-13 at 10:31 -0700, Roberto Mello wrote:
> >
> > I can add a suggestion for the user to consider increasing
> > shared_buffers in accordance with higher max_connections, but it
> > would be better if there was a "rule of thumb" guideline to go
> > along. I'm open to suggestions.
> >
> > I can revise with a similar warning in max_prepared_xacts as well.
> >
> > Sincerely,
> >
> > Roberto
>
> Can a "close enough" rule of thumb be calculated from:
> postgresql.conf -> log_min_messages = debug3
>
> start postgresql with varying max_connections to get
> CreateSharedMemoryAndSemaphores() sizes to generate a rough equation
>
or maybe it would be sufficient to advise to set log_min_messages =
debug3 on a test DB and start/stop it with varying values of
max_connections and look at the differing values in
DEBUG: invoking IpcMemoryCreate(size=...) log messages for themselves.
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Alekseev | 2024-01-22 14:02:03 | Re: Remove unused fields in ReorderBufferTupleBuf |
Previous Message | Bertrand Drouvot | 2024-01-22 13:37:52 | Re: Move walreceiver state assignment (to WALRCV_STREAMING) in WalReceiverMain() |