Re: postgresql 8.3 tps rate

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

In response to

Responses

Browse pgsql-performance by date

  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