Skip site navigation (1) Skip section navigation (2)


From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Scott Carey <scott(at)richrelevance(dot)com>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Brad Nicholson <bnichols(at)ca(dot)afilias(dot)info>, Karl Denninger <karl(at)denninger(dot)net>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-19 21:10:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
Scott Marlowe wrote:
> On Thu, Nov 19, 2009 at 10:01 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> pgbench is actually a pretty awesome i/o tester assuming you have big
>> enough scaling factor
> Seeing as how pgbench only goes to scaling factor of 4000, are the any
> plans on enlarging that number?
I'm doing pgbench tests now on a system large enough for this limit to 
matter, so I'm probably going to have to fix that for 8.5 just to 
complete my own work.

You can use pgbench to either get interesting peak read results, or peak 
write ones, but it's not real useful for things in between.  The 
standard test basically turns into a huge stack of writes to a single 
table, and the select-only one is interesting to gauge either cached or 
uncached read speed (depending on the scale).  It's not very useful for 
getting a feel for how something with a mixed read/write workload does 
though, which is unfortunate because I think that scenario is much more 
common than what it does test.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-performance by date

Next:From: Merlin MoncureDate: 2009-11-19 21:39:18
Subject: Re: SSD + RAID
Previous:From: Greg SmithDate: 2009-11-19 21:04:29
Subject: Re: SSD + RAID

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group