Re: Hardware/OS recommendations for large databases (

From: Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>
To: Luke Lonergan <llonergan(at)greenplum(dot)com>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Joshua Marsh <icub3d(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Hardware/OS recommendations for large databases (
Date: 2005-11-19 21:28:57
Message-ID: 437F9919.20305@paradise.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Luke Lonergan wrote:
> Mark,
>
> On 11/18/05 3:46 PM, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> wrote:
>
>
>>If you alter this to involve more complex joins (e.g 4. way star) and
>>(maybe add a small number of concurrent executors too) - is it still the
>>case?
>
>
> 4-way star, same result, that's part of my point. With Bizgres MPP, the
> 4-way star uses 4 concurrent scanners, though not all are active all the
> time. And that's per segment instance - we normally use one segment
> instance per CPU, so our concurrency is NCPUs plus some.
>

Luke - I don't think I was clear enough about what I was asking, sorry.

I added the more "complex joins" comment because:

- I am happy that seqscan is cpu bound after ~110M/s (It's cpu bound on
my old P3 system even earlier than that....)
- I am curious if the *other* access methods (indexscan, nested loop,
hash, merge, bitmap) also suffer then same fate.

I'm guessing from your comment that you have tested this too, but I
think its worth clarifying!

With respect to Bizgres MPP, scan parallelism is a great addition...
very nice! (BTW - is that in 0.8, or are we talking a new product variant?)

regards

Mark

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Alan Stange 2005-11-20 02:43:48 Re: Hardware/OS recommendations for large databases (
Previous Message Craig A. James 2005-11-19 20:42:50 Re: Perl DBD and an alarming problem