Re: [ADMIN] shared_buffers and shmmax

Hi,
I'm trying to understand what the documentation means by bytes per increment, what is the increment supposed to be bytes, MB, or Kb. I have my shared_buffers set to 577 MB(4 instances) and I'm multiplying by 8400 bytes. I would think I would want to keep everything in bytes and not mulitply bytes times MB, but this is what table 17-2 implies. If I convert 577 to bytes and multiply, my calculator goes exponential on me. I'm going through this table and adding up to see what my shmmax should be (it's 7.5 GB) out of a total memory of 16 GB with 1000 max_connections right now. What should I use as the "increment" value in regards to shared buffers, 577, 590848 or 605028352 ?

a) 577 MB (This seems too small)
b) 590,848 Kb (this seems just right)
c) 605,028,352 bytes (this seems too big, I hope it's not c)

Thanks,
~DjK

Table 17-2. Configuration parameters affecting PostgreSQL's shared memory usage

Name
Approximate multiplier (bytes per increment) as of 8.3

max_connections
1800 + 270 * max_locks_per_transaction

autovacuum_max_workers
1800 + 270 * max_locks_per_transaction

max_prepared_transactions
770 + 270 * max_locks_per_transaction

shared_buffers
8400 (assuming 8 kB BLCKSZ)

wal_buffers
8200 (assuming 8 kB XLOG_BLCKSZ)

max_fsm_relations
70

max_fsm_pages
6

Fixed space requirements
770 kB
_________________________________________________________________
Stay in touch when you're away with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008

shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.

The default shared_buffer of a 1000 is quite conservative. A good starting value is something like 15-25 percent of your main memory or so I am being told. It really depends on how the machine you have your database on is being used. If postgres is the only application using your box then you can even set this to 80% of the memory. You're fine as long as postgres does not have to resort to using the swap space.

If you set shared_buffers so high that it doesn't agree with your systems shmmax then postgres will give you the required value on startup.

Regards,

Val

--- On Tue, 22/7/08, dx k9 <bitsandbytes88(at)hotmail(dot)com> wrote:

> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
> Subject: [ADMIN] shared_buffers and shmmax
> To: "posgres support" <pgsql-admin(at)postgresql(dot)org>
> Date: Tuesday, 22 July, 2008, 2:39 PM
> Hi,
> I'm trying to understand what the documentation means
> by bytes per increment, what is the increment supposed to
> be bytes, MB, or Kb. I have my shared_buffers set to 577
> MB(4 instances) and I'm multiplying by 8400 bytes. I
> would think I would want to keep everything in bytes and
> not mulitply bytes times MB, but this is what table 17-2
> implies. If I convert 577 to bytes and multiply, my
> calculator goes exponential on me. I'm going through
> this table and adding up to see what my shmmax should be
> (it's 7.5 GB) out of a total memory of 16 GB with 1000
> max_connections right now. What should I use as the
> "increment" value in regards to shared buffers,
> 577, 590848 or 605028352 ?
>
> a) 577 MB (This seems too small)
> b) 590,848 Kb (this seems just right)
> c) 605,028,352 bytes (this seems too big, I hope it's
> not c)
>
> Thanks,
> ~DjK
>
> Table 17-2. Configuration parameters affecting
> PostgreSQL's shared memory usage
>
>
>
>
>
>
>
> Name
> Approximate multiplier (bytes per increment) as of 8.3
>
>
> max_connections
> 1800 + 270 * max_locks_per_transaction
>
> autovacuum_max_workers
> 1800 + 270 * max_locks_per_transaction
>
> max_prepared_transactions
> 770 + 270 * max_locks_per_transaction
>
> shared_buffers
> 8400 (assuming 8 kB BLCKSZ)
>
> wal_buffers
> 8200 (assuming 8 kB XLOG_BLCKSZ)
>
> max_fsm_relations
> 70
>
> max_fsm_pages
> 6
>
> Fixed space requirements
> 770 kB
> _________________________________________________________________
> Stay in touch when you're away with Windows Live
> Messenger.
> http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008

__________________________________________________________
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

[ redirecting to pgsql-docs ]

Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk> writes:
>> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
>> I'm trying to understand what the documentation means
>> by bytes per increment, what is the increment supposed to
>> be bytes, MB, or Kb.

> shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.

The table the OP is looking at (table 17.2 in the 8.3 docs) predates
the ability to specify shared_buffers in KB or MB instead of
number-of-buffers. I agree it's not entirely obvious that what it
means is "multiply your setting in KB/MB by 8400/8192". Anybody have
an idea how to clarify things?

regards, tom lane

On 10:45 am 07/22/08 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> [ redirecting to pgsql-docs ]
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?

Perhaps changing the table title?
Table 17-2. Configuration parameters affecting PostgreSQL's shared memory
usage when not using a size modified.

Alternatively, below the table we could have clarifications such as:
Previously, it was not possible to indicate a size modified such as M for
Megabytes. As of version X.Y, Postgresql allows to use M, for MB, GB for GB
and more... See.... for all values.

When not using one of the new modifiers the space used would be the number
you enter times the constant on the right side of the table.
For example using 100 shared_buffers would be 100 x 8400 = 840,000 bytes.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message

>> shared_buffers is in disk block size, typically 8K

> The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> the ability to specify shared_buffers in KB or MB instead of
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?

Bite the bullet and start showing the buffer settings as a pure number of bytes
everywhere, and get rid of the confusing '8kB' unit in pg_settings? Things like
this don't help our cause:

test=# show shared_buffers;
shared_buffers
----------------
24MB
(1 row)

test=# set temp_buffers = '24MB';
SET

test=# show temp_buffers;
temp_buffers
--------------
3072

test=# select name, setting from pg_settings where name ~ 'buffers';
name | setting
----------------+---------
shared_buffers | 3072
temp_buffers | 3072
wal_buffers | 8

test=# show wal_buffers;
wal_buffers
-------------
64kB

--
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation
PGP Key: 0x14964AC8 200807241351
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkiIwYYACgkQvJuQZxSWSsiY5wCfU/tca+1JakWaMCDDRHEHk/Uj
1rcAoMi1FNGSpJhyXWde1psygq6v3MlS
=gCPg
-----END PGP SIGNATURE-----

On Thu, 2008-07-24 at 17:54 +0000, Greg Sabino Mullane wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> NotDashEscaped: You need GnuPG to verify this message
>
>
> >> shared_buffers is in disk block size, typically 8K
>
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings?

+1

We have helper functions like pg_size_pretty() to resolve the other
issues.

Joshua D. Drake

--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
United States PostgreSQL Association: http://www.postgresql.us/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate

On Thu, 24 Jul 2008, Greg Sabino Mullane wrote:

> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings?

There's already some changes needed in this area needed to execute the
full GUC cleanup/wizard plan that's being worked on. The pg_settings view
really should show the value both as the user input it and as it's stored
internally for cases like these, which lowers the confusion here a bit
even without going so far as converting everything to bytes.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

Greg Smith wrote:
> On Thu, 24 Jul 2008, Greg Sabino Mullane wrote:
>
> > Bite the bullet and start showing the buffer settings as a pure number of bytes
> > everywhere, and get rid of the confusing '8kB' unit in pg_settings?
>
> There's already some changes needed in this area needed to execute the
> full GUC cleanup/wizard plan that's being worked on. The pg_settings view
> really should show the value both as the user input it and as it's stored
> internally for cases like these, which lowers the confusion here a bit
> even without going so far as converting everything to bytes.

Is this a TODO?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

On Tue, 12 Aug 2008, Bruce Momjian wrote:

>> There's already some changes needed in this area needed to execute the
>> full GUC cleanup/wizard plan that's being worked on. The pg_settings view
>> really should show the value both as the user input it and as it's stored
>> internally for cases like these, which lowers the confusion here a bit
>> even without going so far as converting everything to bytes.
>
> Is this a TODO?

I don't think you need yet another TODO for every detail, the existing
TODO "Add external tool to auto-tune some postgresql.conf parameters" has
to squash a bunch of issues in this area. This particular issue Greg
raised will already be improved significantly if executing the larger
project plan at http://wiki.postgresql.org/wiki/GUCS_Overhaul

This week Robert Treat and I have been doing a lot of work on "Problem #1"
there, "Most people have no idea how to set [GUCs]" which I know some
people wanted to see a more formal document for before mucking with any of
the code. I'll have something to announce there shortly.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

On Aug 12, 2008, at 2:43 PM, Greg Smith wrote:
> On Tue, 12 Aug 2008, Bruce Momjian wrote:
>>> There's already some changes needed in this area needed to
>>> execute the
>>> full GUC cleanup/wizard plan that's being worked on. The
>>> pg_settings view
>>> really should show the value both as the user input it and as
>>> it's stored
>>> internally for cases like these, which lowers the confusion here
>>> a bit
>>> even without going so far as converting everything to bytes.
>>
>> Is this a TODO?
>
> I don't think you need yet another TODO for every detail, the
> existing TODO "Add external tool to auto-tune some postgresql.conf
> parameters" has to squash a bunch of issues in this area. This
> particular issue Greg raised will already be improved significantly
> if executing the larger project plan at http://wiki.postgresql.org/
> wiki/GUCS_Overhaul

Yeah, but OTOH it's not clear at all when we might see such a tool,
while clarifying this stuff would help people immediately... I think
a TODO would be good to make sure this doesn't fall through the cracks.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

Tom Lane wrote:
> [ redirecting to pgsql-docs ]
>
> Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk> writes:
> >> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
> >> I'm trying to understand what the documentation means
> >> by bytes per increment, what is the increment supposed to
> >> be bytes, MB, or Kb.
>
> > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
>
> The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> the ability to specify shared_buffers in KB or MB instead of
> number-of-buffers. I agree it's not entirely obvious that what it
> means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> an idea how to clarify things?

I have updated the table title to be clearer.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

I have added this TODO item:

Rationalize the discrepancy between settings that use values in bytes
and SHOW that returns the object count

* http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php

---------------------------------------------------------------------------

Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
> NotDashEscaped: You need GnuPG to verify this message
>
>
> >> shared_buffers is in disk block size, typically 8K
>
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> Bite the bullet and start showing the buffer settings as a pure number of bytes
> everywhere, and get rid of the confusing '8kB' unit in pg_settings? Things like
> this don't help our cause:
>
> test=# show shared_buffers;
> shared_buffers
> ----------------
> 24MB
> (1 row)
>
> test=# set temp_buffers = '24MB';
> SET
>
> test=# show temp_buffers;
> temp_buffers
> --------------
> 3072
>
> test=# select name, setting from pg_settings where name ~ 'buffers';
> name | setting
> ----------------+---------
> shared_buffers | 3072
> temp_buffers | 3072
> wal_buffers | 8
>
> test=# show wal_buffers;
> wal_buffers
> -------------
> 64kB
>
>
> --
> Greg Sabino Mullane greg(at)turnstep(dot)com
> End Point Corporation
> PGP Key: 0x14964AC8 200807241351
> http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
> -----BEGIN PGP SIGNATURE-----
>
> iEYEAREDAAYFAkiIwYYACgkQvJuQZxSWSsiY5wCfU/tca+1JakWaMCDDRHEHk/Uj
> 1rcAoMi1FNGSpJhyXWde1psygq6v3MlS
> =gCPg
> -----END PGP SIGNATURE-----
>
>
>
> --
> Sent via pgsql-docs mailing list (pgsql-docs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Tom Lane wrote:
> > [ redirecting to pgsql-docs ]
> >
> > Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk> writes:
> > >> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
> > >> I'm trying to understand what the documentation means
> > >> by bytes per increment, what is the increment supposed to
> > >> be bytes, MB, or Kb.
> >
> > > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
> >
> > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > the ability to specify shared_buffers in KB or MB instead of
> > number-of-buffers. I agree it's not entirely obvious that what it
> > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > an idea how to clarify things?
>
> I have updated the table title to be clearer.

I don't find it any clearer ... I think the missing clue is that if you
specify shared_buffers values in MB, you must divide the value by block
size.

> ***************
> *** 1119,1125 ****
>
> <row>
> <entry>Fixed space requirements</>
> ! <entry>770 kB</entry>
> </row>
> </tbody>
> </tgroup>
> --- 1119,1125 ----
>
> <row>
> <entry>Fixed space requirements</>
> ! <entry>770 k</entry>
> </row>
> </tbody>
> </tgroup>

This change is wrong, why did you do it?

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > [ redirecting to pgsql-docs ]
> > >
> > > Valentin Bogdanov <valiouk(at)yahoo(dot)co(dot)uk> writes:
> > > >> From: dx k9 <bitsandbytes88(at)hotmail(dot)com>
> > > >> I'm trying to understand what the documentation means
> > > >> by bytes per increment, what is the increment supposed to
> > > >> be bytes, MB, or Kb.
> > >
> > > > shared_buffers is in disk block size, typically 8K, at least that's what it is on Linux platforms. shmmax is quite simply in bytes.
> > >
> > > The table the OP is looking at (table 17.2 in the 8.3 docs) predates
> > > the ability to specify shared_buffers in KB or MB instead of
> > > number-of-buffers. I agree it's not entirely obvious that what it
> > > means is "multiply your setting in KB/MB by 8400/8192". Anybody have
> > > an idea how to clarify things?
> >
> > I have updated the table title to be clearer.
>
> I don't find it any clearer ... I think the missing clue is that if you
> specify shared_buffers values in MB, you must divide the value by block
> size.

Well, the heading says "object" now so I thought it would suggest we are
talking about objects and not bytes.

> > ***************
> > *** 1119,1125 ****
> >
> > <row>
> > <entry>Fixed space requirements</>
> > ! <entry>770 kB</entry>
> > </row>
> > </tbody>
> > </tgroup>
> > --- 1119,1125 ----
> >
> > <row>
> > <entry>Fixed space requirements</>
> > ! <entry>770 k</entry>
> > </row>
> > </tbody>
> > </tgroup>
>
> This change is wrong, why did you do it?

The heading says "bytes" so having the "B" was unnecessary and possibly
confusing.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Alvaro Herrera wrote:
>> I don't find it any clearer ... I think the missing clue is that if you
>> specify shared_buffers values in MB, you must divide the value by block
>> size.

> Well, the heading says "object" now so I thought it would suggest we are
> talking about objects and not bytes.

I'm with Alvaro: neither of those changes were improvements.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Alvaro Herrera wrote:
> >> I don't find it any clearer ... I think the missing clue is that if you
> >> specify shared_buffers values in MB, you must divide the value by block
> >> size.
>
> > Well, the heading says "object" now so I thought it would suggest we are
> > talking about objects and not bytes.
>
> I'm with Alvaro: neither of those changes were improvements.

OK, I never got the change applied because of Alvaro's objection so
there is nothing to revert. Alvaro said he has an idea for improved
wording; I do not.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:

> OK, I never got the change applied because of Alvaro's objection so
> there is nothing to revert. Alvaro said he has an idea for improved
> wording; I do not.

I think we should add a more explicit note, like in the attached patch.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > OK, I never got the change applied because of Alvaro's objection so
> > there is nothing to revert. Alvaro said he has an idea for improved
> > wording; I do not.
>
> I think we should add a more explicit note, like in the attached patch.

Committed. Bruce told me on IM he still wants to do more changes.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> >
> > > OK, I never got the change applied because of Alvaro's objection so
> > > there is nothing to revert. Alvaro said he has an idea for improved
> > > wording; I do not.
> >
> > I think we should add a more explicit note, like in the attached patch.
>
> Committed. Bruce told me on IM he still wants to do more changes.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.

OK, updated patch. I added item descriptions and removed Alvaro's
paragraph; I worked with Alvaro on this patch.

You can see the output in table 17-2:

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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> OK, updated patch. I added item descriptions and removed Alvaro's
> paragraph; I worked with Alvaro on this patch.

This still seems pretty misleading, as for example

> <tbody>
> <row>
> <entry><xref linkend="guc-max-connections"></>
> ! <entry>1800 + 270 * <xref
> ! linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
> </row>

sounds like it might mean bytes per *active* connection, when of course
the correct way to figure it is by multiplying by max_connections.
If you're going to give a formula, why not just give a formula, eg

(1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > OK, updated patch. I added item descriptions and removed Alvaro's
> > paragraph; I worked with Alvaro on this patch.
>
> This still seems pretty misleading, as for example
>
> > <tbody>
> > <row>
> > <entry><xref linkend="guc-max-connections"></>
> > ! <entry>1800 + 270 * <xref
> > ! linkend="guc-max-locks-per-transaction"> bytes per connection</entry>
> > </row>
>
> sounds like it might mean bytes per *active* connection, when of course
> the correct way to figure it is by multiplying by max_connections.
> If you're going to give a formula, why not just give a formula, eg
>
> (1800 + 270 * max_locks_per_transaction) * (max_connections + autovacuum_max_workers)
>
> regards, tom lane

You mean like this:

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

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Tom Lane wrote:
>> If you're going to give a formula, why not just give a formula, eg

> You mean like this:
> http://momjian.us/tmp/pgsql/kernel-resources.html

Yeah, more or less. A couple thoughts now that I see it worked out:

* Combining the entries for max_connections and autovacuum_max_workers
is probably just making it look more complicated than it needs to.
How about two rows that just happen to have similar formulas, viz

max_connections (1800 + 270 * max_locks_per_transaction) * max_connections
autovacuum_max_workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers

* The right-hand column header should be something like "Approximate
shared memory bytes..." to avoid the impression that these formulas
are meant to be exact.

* 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

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > Tom Lane wrote:
> >> If you're going to give a formula, why not just give a formula, eg
>
> > You mean like this:
> > http://momjian.us/tmp/pgsql/kernel-resources.html
>
> Yeah, more or less. A couple thoughts now that I see it worked out:
>
> * Combining the entries for max_connections and autovacuum_max_workers
> is probably just making it look more complicated than it needs to.
> How about two rows that just happen to have similar formulas, viz
>
> max_connections (1800 + 270 * max_locks_per_transaction) * max_connections
> autovacuum_max_workers (1800 + 270 * max_locks_per_transaction) * autovacuum_max_workers
>
> * The right-hand column header should be something like "Approximate
> shared memory bytes..." to avoid the impression that these formulas
> are meant to be exact.
>
> * 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.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:

> 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

This version seems good to me, except please put back the B to the end
of "770 k".

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > 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
>
> This version seems good to me, except please put back the B to the end
> of "770 k".

Patch applied with "B" re-added, though I would like to mention again
that it is inconsistent because we don't mention bytes in any other row
in that column.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

Bruce Momjian wrote:
> Alvaro Herrera wrote:

> > This version seems good to me, except please put back the B to the end
> > of "770 k".
>
> Patch applied with "B" re-added, though I would like to mention again
> that it is inconsistent because we don't mention bytes in any other row
> in that column.

The heading already says "bytes".

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.