Luke Lonergan wrote:
Mark,
On 11/18/05 3:46 PM, "Mark Kirkwood" <markir@xxxxxxxxxxxxxxx> 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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
