From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Ibrahim Harrani <ibrahim(dot)harrani(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: postgresql 8.3 tps rate |
Date: | 2009-01-23 03:52:47 |
Message-ID: | Pine.GSO.4.64.0901222247590.12661@westnet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 22 Jan 2009, Alvaro Herrera wrote:
> Also, I think you should set the "scale" in the prepare step (-i) at
> least as high as the number of clients you're going to use. (I dimly
> recall some recent development in this area that might mean I'm wrong.)
The idea behind that maxim (clients>=scale) is that locking on the smaller
tables will bottleneck resuls if you don't follow that advice. It's a bit
messier than that though. Increasing the scale will also make the
database larger, and once it gets bigger than available RAM your results
are going to dive hard because of that, more so than the locking would
have held you back.
All kind of irrelevant for Ibrahim's case, because if you're not getting
more than 50MB/s out of your disks the pgbench results are kind of moot
anyway--there's a larger problem to sort out first.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2009-01-23 05:52:05 | Re: caching indexes and pages? |
Previous Message | Greg Smith | 2009-01-23 03:44:51 | Re: dbt-2 tuning results with postgresql-8.3.5 |