Re: [PATCHES] [HACKERS] BLCKSZ fun facts

2007-02-23 Thread Bruce Momjian
Peter Eisentraut wrote:
 Bruce Momjian wrote:
  I have implemented your ideas for checking BLCKSZ = 1024,
 
 I think the check should be were the issue arises, not in some distant 
 file without explanation.

OK, moved to guc.c.
-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

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

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [PATCHES] [HACKERS] BLCKSZ fun facts

2007-02-21 Thread Peter Eisentraut
Bruce Momjian wrote:
 I have implemented your ideas for checking BLCKSZ = 1024,

I think the check should be were the issue arises, not in some distant 
file without explanation.

-- 
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: [PATCHES] [HACKERS] BLCKSZ fun facts

2007-02-20 Thread Bruce Momjian

I have implemented your ideas for checking BLCKSZ = 1024, and having
initdb adjust shared buffers checks based on BLCKSZ.

Patch attached and applied.

---

Peter Eisentraut wrote:
 The smallest BLCKSZ that you can compile is 256.  But ...
 
 The smallest BLCKSZ that actually works is 1024, because of this code in 
 guc.c:
 
 case GUC_UNIT_BLOCKS:
 val /= (BLCKSZ / 1024);
 
 Maybe it's worth adding an #error here to prevent smaller sizes being 
 used?
 
 The smallest BLCKSZ that passes the regression tests is 4096.  With 
 smaller settings your get half a dozen ordering differences, which 
 seems OK.
 
 The shared memory configuration code in initdb doesn't know about 
 BLCKSZ, so with smaller sizes you get less shared buffers.  Maybe that 
 is worth fixing sometime.
 
 Aside from that my pgbench testing clearly shows that block sizes larger 
 than 2048 become progressively slower.  Go figure.
 
 -- 
 Peter Eisentraut
 http://developer.postgresql.org/~petere/
 
 ---(end of broadcast)---
 TIP 3: Have you checked our extensive FAQ?
 
http://www.postgresql.org/docs/faq

-- 
  Bruce Momjian  [EMAIL PROTECTED]  http://momjian.us
  EnterpriseDB   http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: src/bin/initdb/initdb.c
===
RCS file: /cvsroot/pgsql/src/bin/initdb/initdb.c,v
retrieving revision 1.133
diff -c -c -r1.133 initdb.c
*** src/bin/initdb/initdb.c	16 Feb 2007 02:10:07 -	1.133
--- src/bin/initdb/initdb.c	20 Feb 2007 23:46:19 -
***
*** 1208,1214 
  
  	for (i = 0; i  bufslen; i++)
  	{
! 		test_buffs = trial_bufs[i];
  		if (test_buffs = ok_buffers)
  		{
  			test_buffs = ok_buffers;
--- 1208,1215 
  
  	for (i = 0; i  bufslen; i++)
  	{
! 		/* Use same amount of memory, independent of BLCKSZ */
! 		test_buffs = (trial_bufs[i] * 8192) / BLCKSZ;
  		if (test_buffs = ok_buffers)
  		{
  			test_buffs = ok_buffers;
Index: src/include/pg_config_manual.h
===
RCS file: /cvsroot/pgsql/src/include/pg_config_manual.h,v
retrieving revision 1.24
diff -c -c -r1.24 pg_config_manual.h
*** src/include/pg_config_manual.h	6 Feb 2007 09:16:08 -	1.24
--- src/include/pg_config_manual.h	20 Feb 2007 23:46:19 -
***
*** 25,30 
--- 25,34 
   */
  #define BLCKSZ	8192
  
+ #if BLCKSZ  1024
+ #error BLCKSZ must be = 1024
+ #endif
+ 
  /*
   * RELSEG_SIZE is the maximum number of blocks allowed in one disk
   * file.  Thus, the maximum size of a single file is RELSEG_SIZE *

---(end of broadcast)---
TIP 6: explain analyze is your friend