From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
Cc: | Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu>, Christopher Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: APR 1.0 released |
Date: | 2004-10-08 00:36:33 |
Message-ID: | 200410080036.i980aXs03880@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Added to TODO:
* Consider parallel processing a single query
This would involve using multiple threads or processes to do optimization,
sorting, or execution of single query. The major advantage of such a
feature would be to allow multiple CPUs to work together to process a
single query.
---------------------------------------------------------------------------
Jim C. Nasby wrote:
> Any chance of having query parallelization added to TODO? I'm guessing
> it will be a huge job, but it's also one of the places where the 'big 3'
> have a huge advantage in scalability.
>
> On Mon, Sep 13, 2004 at 10:24:05AM -0700, Sailesh Krishnamurthy wrote:
> > >>>>> "CB" == Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> >
> > CB> futile discussions ask for it. Notably, on an SMP system, it
> > CB> would be a neat idea for complex queries involving joins to
> > CB> split themselves so that different parts run in separate
> > CB> threads.
> >
> > You don't really need threads for this. All you need is to have
> > multiple backends and use queues to exchange tuples at specific
> > points. This is much like the Exchange operator in Volcano.
> >
> > CB> The other Way, Way Cool part would be for queries that are
> > CB> scanning big tables to split the scans into unions of partial
> > CB> scans, so that on an 8 CPU box you'd take the "Big 4GB Table"
> > CB> and have 8 threads simultaneously scanning different parts of
> > CB> it. (And making ARC all the more important :-).)
> >
> > Again this can be done without threads .. you just need inter-process
> > communication.
> >
> > (BTW, there is at least one commercial system that follows exactly
> > this model).
> >
> > --
> > Pip-pip
> > Sailesh
> > http://www.cs.berkeley.edu/~sailesh
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
> --
> Jim C. Nasby, Database Consultant decibel(at)decibel(dot)org
> Give your computer some brain candy! www.distributed.net Team #1828
>
> Windows: "Where do you want to go today?"
> Linux: "Where do you want to go tomorrow?"
> FreeBSD: "Are you guys coming, or what?"
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-08 00:38:57 | Re: more dirmod CYGWIN |
Previous Message | Bruce Momjian | 2004-10-08 00:27:21 | Re: more dirmod CYGWIN (was: APR 1.0 released) |