Questions about guc units

Am Montag, 25. September 2006 04:04 schrieb ITAGAKI Takahiro:

#shared_buffers = 32000kB # min 128kB or max_connections*16kB
#temp_buffers = 8000kB # min 800kB
#effective_cache_size = 8000kB

Are there any reasons to continue to use 1000-unit numbers? Megabyte-unit
(32MB and 8MB) seems to be more friendly for users. It increases some
amount of values (4000 vs. 4096), but there is little in it.

The reason with the shared_buffers is that the detection code in initdb has
400kB as minimum value, and it would be pretty complicated to code the
detection code to handle both kB and MB units. If someone wants to try it,
though, please go ahead.

We could probably change the others.

#max_fsm_pages = 1600000 # min max_fsm_relations*16, 6 bytes each
#wal_buffers = 8 # min 4, 8kB each

They don't have units now, but should they have GUC_UNIT_BLOCKS and
GUC_UNIT_XLOG_BLCKSZ unit? I feel inconsistency in them.

max_fsm_pages doesn't have a discernible unit, but wal_buffers probably
should.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, Sep 25, 2006 at 10:03:50AM +0200, Peter Eisentraut wrote:

Am Montag, 25. September 2006 04:04 schrieb ITAGAKI Takahiro:

#shared_buffers = 32000kB # min 128kB or max_connections*16kB
#temp_buffers = 8000kB # min 800kB
#effective_cache_size = 8000kB

Are there any reasons to continue to use 1000-unit numbers? Megabyte-unit
(32MB and 8MB) seems to be more friendly for users. It increases some
amount of values (4000 vs. 4096), but there is little in it.

The reason with the shared_buffers is that the detection code in initdb has
400kB as minimum value, and it would be pretty complicated to code the
detection code to handle both kB and MB units. If someone wants to try it,
though, please go ahead.

What about 0.4MB? Granted, it's uglier than 400kB, but anyone running on
a machine that can't handle at least 1MB is already in the "pretty ugly"
realm...
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)

Jim C. Nasby wrote:

The reason with the shared_buffers is that the detection code in
initdb has 400kB as minimum value, and it would be pretty
complicated to code the detection code to handle both kB and MB
units. If someone wants to try it, though, please go ahead.

What about 0.4MB?

That isn't valid code, so I don't know how that helps.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Sep 25, 2006, at 1:03 AM, Peter Eisentraut wrote:

Am Montag, 25. September 2006 04:04 schrieb ITAGAKI Takahiro:

#shared_buffers = 32000kB # min 128kB or max_connections*16kB
#temp_buffers = 8000kB # min 800kB
#effective_cache_size = 8000kB

Are there any reasons to continue to use 1000-unit numbers?
Megabyte-unit
(32MB and 8MB) seems to be more friendly for users. It increases some
amount of values (4000 vs. 4096), but there is little in it.

The reason with the shared_buffers is that the detection code in
initdb has
400kB as minimum value, and it would be pretty complicated to code the
detection code to handle both kB and MB units. If someone wants to
try it,
though, please go ahead.

Seems like the unit used for shared_buffers (and others) should be
megabytes then with a minimum of 1 (or more). Is less than 1MB
granularity really useful here? On modern hardware 1MB of RAM is in
the noise.

-Casey

Peter Eisentraut <peter_e@gmx.net> wrote:

#max_fsm_pages = 1600000 # min max_fsm_relations*16, 6 bytes each

max_fsm_pages doesn't have a discernible unit

Yes, max_fsm_*pages* doesn't have a unit, but can we treat the value as
"the amount of trackable database size by fsm" or "estimated database size" ?
(the latter is a bit too radical interpretation, though.)
So I think it is not so odd to give a unit to max_fsm_pages.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

The attached patch changes units of the some default values in postgresql.conf.

- shared_buffers = 32000kB => 32MB
- temp_buffers = 8000kB => 8MB
- wal_buffers = 8 => 64kB

The code of initdb was a bit modified to write MB-unit values.
Values greater than 8000kB are rounded out to MB.

GUC_UNIT_XBLOCKS is added for wal_buffers. It is like GUC_UNIT_BLOCKS,
but uses XLOG_BLCKSZ instead of BLCKSZ.

Also, I cleaned up the test of GUC_UNIT_* flags in preparation to
add more unit flags in less bits.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

Casey Duncan wrote:

Seems like the unit used for shared_buffers (and others) should be
megabytes then with a minimum of 1 (or more). Is less than 1MB
granularity really useful here?

Yes, there are platforms that allow as little as 512 kB of shared memory
by default.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Patch applied. Thanks.

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

ITAGAKI Takahiro wrote:

The attached patch changes units of the some default values in postgresql.conf.

- shared_buffers = 32000kB => 32MB
- temp_buffers = 8000kB => 8MB
- wal_buffers = 8 => 64kB

The code of initdb was a bit modified to write MB-unit values.
Values greater than 8000kB are rounded out to MB.

GUC_UNIT_XBLOCKS is added for wal_buffers. It is like GUC_UNIT_BLOCKS,
but uses XLOG_BLCKSZ instead of BLCKSZ.

Also, I cleaned up the test of GUC_UNIT_* flags in preparation to
add more unit flags in less bits.

Regards,
---
ITAGAKI Takahiro
NTT Open Source Software Center

[ Attachment, skipping... ]

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

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