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

From M. Edward (Ed) Borasky
Subject Re: postgresql 8.3 tps rate
Date
Msg-id 497C920E.20404@cesmail.net
Whole thread Raw
In response to Re: postgresql 8.3 tps rate  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: postgresql 8.3 tps rate  ("M. Edward (Ed) Borasky" <znmeb@cesmail.net>)
List pgsql-performance
Greg Smith wrote:
> 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
>
IIRC this is a FreeBSD system, not Linux. Could there be some filesystem
performance issue here? I know zero about FreeBSD filesystems.

Also, is there a separate driver machine you can use to run pgbench? The
pgbench client uses resources, which could lower your throughput.

--
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

pgsql-performance by date:

Previous
From: david@lang.hm
Date:
Subject: Re: SSD performance
Next
From: "M. Edward (Ed) Borasky"
Date:
Subject: Re: postgresql 8.3 tps rate