From: | "M(dot) Edward (Ed) Borasky" <znmeb(at)cesmail(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: postgresql 8.3 tps rate |
Date: | 2009-01-25 16:23:42 |
Message-ID: | 497C920E.20404@cesmail.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gregsmith(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | M. Edward (Ed) Borasky | 2009-01-25 17:05:00 | Re: postgresql 8.3 tps rate |
Previous Message | david | 2009-01-25 13:16:40 | Re: SSD performance |