Thread

1. 8rc2 & BLCKSZ

   jg <jg@rilk.com> — 2004-12-22T16:31:50Z

   Hi,
   
   A small test with 8rc2 and BLCKSZ of 8k and 32k.
   It seems there is a 10% increase in the number of transactions by 
   second.
   Does someone plan to carefully test the impact of BLCKSZ ?
   
   Cordialement,
   Jean-Gérard Pailloncy
   
   with 8k:
    > /test/bin/pgbench -c 10 -t 300 test
   starting vacuum...end.
   transaction type: TPC-B (sort of)
   scaling factor: 10
   number of clients: 10
   number of transactions per client: 300
   number of transactions actually processed: 3000/3000
   ...
   tps = 26.662146 (excluding connections establishing)
   tps = 23.742071 (excluding connections establishing)
   tps = 28.323828 (excluding connections establishing)
   tps = 27.944931 (excluding connections establishing)
   tps = 25.898393 (excluding connections establishing)
   tps = 26.727316 (excluding connections establishing)
   tps = 27.499692 (excluding connections establishing)
   tps = 25.430853 (excluding connections establishing)
   
   with 32k:
    > /test/bin/pgbench -c 10 -t 300 test
   starting vacuum...end.
   transaction type: TPC-B (sort of)
   scaling factor: 10
   number of clients: 10
   number of transactions per client: 300
   number of transactions actually processed: 3000/3000
   ...
   tps = 28.609049 (excluding connections establishing)
   tps = 29.978503 (excluding connections establishing)
   tps = 30.502606 (excluding connections establishing)
   tps = 33.406386 (excluding connections establishing)
   tps = 30.422134 (excluding connections establishing)
   tps = 26.878762 (excluding connections establishing)
   tps = 31.461116 (excluding connections establishing)
   
   
   

2. Re: 8rc2 & BLCKSZ

   Vivek Khera <khera@kcilink.com> — 2004-12-22T20:51:02Z

   >>>>> "PJ" == Pailloncy Jean-Gerard <jg@rilk.com> writes:
   
   PJ> Hi,
   PJ> A small test with 8rc2 and BLCKSZ of 8k and 32k.
   PJ> It seems there is a 10% increase in the number of transactions by
   PJ> second.
   PJ> Does someone plan to carefully test the impact of BLCKSZ ?
   
   One of the suggestions handed to me a long time ago for speeding up PG
   on FreeBSD was to double the default blocksize in PG.  I tried it, but
   found not a significant enough speed up to make it worth the trouble
   to remember to patch every version of Pg during the upgrade path (ie,
   7.4.0 -> 7.4.2 etc.)  Forgetting to do that would be disastrous!
   
   
   -- 
   =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
   Vivek Khera, Ph.D.                Khera Communications, Inc.
   Internet: khera@kciLink.com       Rockville, MD  +1-301-869-4449 x806
   AIM: vivekkhera Y!: vivek_khera   http://www.khera.org/~vivek/
   
   

3. Re: 8rc2 & BLCKSZ

   Tom Lane <tgl@sss.pgh.pa.us> — 2004-12-22T21:04:50Z

   Vivek Khera <khera@kcilink.com> writes:
   > One of the suggestions handed to me a long time ago for speeding up PG
   > on FreeBSD was to double the default blocksize in PG.  I tried it, but
   > found not a significant enough speed up to make it worth the trouble
   > to remember to patch every version of Pg during the upgrade path (ie,
   > 7.4.0 -> 7.4.2 etc.)  Forgetting to do that would be disastrous!
   
   Not really --- the postmaster will refuse to start if the BLCKSZ shown
   in pg_control doesn't match what is compiled in.  I concur though that
   there may be no significant performance gain.  For some workloads there
   may well be a performance loss from increasing BLCKSZ.
   
   			regards, tom lane
   
   

4. Re: 8rc2 & BLCKSZ

   Mario Weilguni <mweilguni@sime.com> — 2004-12-23T07:00:41Z

   Am Mittwoch, 22. Dezember 2004 22:04 schrieb Tom Lane:
   > Vivek Khera <khera@kcilink.com> writes:
   > > One of the suggestions handed to me a long time ago for speeding up PG
   > > on FreeBSD was to double the default blocksize in PG.  I tried it, but
   > > found not a significant enough speed up to make it worth the trouble
   > > to remember to patch every version of Pg during the upgrade path (ie,
   > > 7.4.0 -> 7.4.2 etc.)  Forgetting to do that would be disastrous!
   >
   > Not really --- the postmaster will refuse to start if the BLCKSZ shown
   > in pg_control doesn't match what is compiled in.  I concur though that
   > there may be no significant performance gain.  For some workloads there
   > may well be a performance loss from increasing BLCKSZ.
   
   I've several databases of the same version 7.2 with rowsizes from 8k and 32k 
   with the same workload (a content management system), and the performance of 
   the 32k variants is slightly better for a few queries, overall responsivness 
   seems to better with 8k (maybe because the 8k variant has 4x more buffers).
   
   Regards,
    Mario Weilguni