| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
| Cc: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Huge Data sets, simple queries |
| Date: | 2006-02-01 05:53:06 |
| Message-ID: | C0058CC2.1B6B1%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Jeffrey,
On 1/31/06 8:09 PM, "Jeffrey W. Baker" <jwbaker(at)acm(dot)org> wrote:
>> ... Prove it.
> I think I've proved my point. Software RAID1 read balancing provides
> 0%, 300%, 100%, and 100% speedup on 1, 2, 4, and 8 threads,
> respectively. In the presence of random I/O, the results are even
> better.
> Anyone who thinks they have a single-threaded workload has not yet
> encountered the autovacuum daemon.
Good data - interesting case. I presume from your results that you had to
make the I/Os non-overlapping (the "skip" option to dd) in order to get the
concurrent access to work. Why the particular choice of offset - 3.2GB in
this case?
So - the bandwidth doubles in specific circumstances under concurrent
workloads - not relevant to "Huge Data sets, simple queries", but possibly
helpful for certain kinds of OLTP applications.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeffrey W. Baker | 2006-02-01 08:25:13 | Re: Huge Data sets, simple queries |
| Previous Message | Tom Lane | 2006-02-01 05:49:43 | Re: partitioning and locking problems |