From: | Matthew <matthew(at)flymine(dot)org> |
---|---|
To: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Utilizing multiple cores for one query |
Date: | 2007-12-04 13:24:35 |
Message-ID: | Pine.LNX.4.58.0712041319210.3731@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, 1 Dec 2007, Jonah H. Harris wrote:
> I believe the threads you're talking about were related to scanning,
> not parallel query. Though, when Qingqing and I were discussing
> parallel query a little over a year ago, I do seem to recall several
> uninformed opinions stating that sequential scans were the only thing
> it could be useful for.
I would imagine sorting a huge set of results would benefit from
multi-threading, because it can be split up into separate tasks. Heck,
Postgres *already* splits sorting up into multiple chunks when the results
to sort are bigger than fit in memory.
This would benefit a lot of multi-table joins, because being able to sort
a table faster would enable merge joins to be used at lower cost. That's
particularly valuable when you're doing a large summary multi-table join
that uses most of the database contents.
Matthew
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. --Donald Knuth
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Mielke | 2007-12-04 13:45:24 | Re: RAID arrays and performance |
Previous Message | Matthew | 2007-12-04 13:16:57 | Re: RAID arrays and performance |