Re: [HACKERS] Questions about guc units
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/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] 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 = 160# 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/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Questions about guc units
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[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Questions about guc units
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Questions about guc units
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Questions about guc units
Peter Eisentraut [EMAIL PROTECTED] wrote: #max_fsm_pages = 160# 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Questions about guc units
Hi hackers, I have some questions about guc units, new feature in 8.2. #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. #max_fsm_pages = 160# 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. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
