Re: postgresql 8.3 tps rate - Mailing list pgsql-performance

From Greg Smith
Subject Re: postgresql 8.3 tps rate
Date
Msg-id Pine.GSO.4.64.0901222247590.12661@westnet.com
Whole thread Raw
In response to Re: postgresql 8.3 tps rate  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: postgresql 8.3 tps rate  ("M. Edward (Ed) Borasky" <znmeb@cesmail.net>)
List 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@gregsmith.com http://www.gregsmith.com Baltimore, MD

pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: dbt-2 tuning results with postgresql-8.3.5
Next
From: Craig Ringer
Date:
Subject: Re: caching indexes and pages?