Re: [ADMIN] shared_buffers and shmmax - Mailing list pgsql-docs

From Bruce Momjian
Subject Re: [ADMIN] shared_buffers and shmmax
Date
Msg-id 200812171411.mBHEBKX26736@momjian.us
Whole thread Raw
In response to Re: [ADMIN] shared_buffers and shmmax  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [ADMIN] shared_buffers and shmmax
List pgsql-docs
Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Tom Lane wrote:
> >> * If we do it like this then the left-hand column is really redundant,
> >> not to say wrong because the right-hand formulas depend on more than
> >> the single variable mentioned.  How about something like
> >>
> >> Table 17-2    PostgreSQL shared memory usage
> >>
> >> Purpose                Approximate number of bytes required (as of 8.3)
> >>
> >> Per-connection state        (1800 + 270 * max_locks_per_transaction) * max_connections
> >> Autovacuum worker state        (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
> >> Prepared transaction state    ...
> >> Shared disk buffers        ...
> >> WAL buffers            ...
> >> Fixed space requirements    770kB
>
> > OK, I updated it again:
>
> >     http://momjian.us/tmp/pgsql/kernel-resources.html
>
> > I did change your left column wording because it could be interpreted as
> > something that changes during server execution, e.g. connections.
>
> [ shrug... ]  I don't find what you did to be an improvement over what
> I suggested, but I don't have time to argue about it.

I decided I didn't like what I did either;  updated version with new
headings and shorter descriptions:

    http://momjian.us/tmp/pgsql/kernel-resources.html

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-docs by date:

Previous
From: Tom Lane
Date:
Subject: Re: [ADMIN] shared_buffers and shmmax
Next
From: Alvaro Herrera
Date:
Subject: Re: [ADMIN] shared_buffers and shmmax