| 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: | 4B05B457.90507@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-11-19 21:39:18 | Re: SSD + RAID |
| Previous Message | Greg Smith | 2009-11-19 21:04:29 | Re: SSD + RAID |