Thread: Re: [DOCS] [ADMIN] shared_buffers and shmmax
-----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@turnstep.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@gregsmith.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@momjian.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@gregsmith.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@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
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@turnstep.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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-docs
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +