Hans-J�rgen Sch�nig wrote:
> >>Stage 2) Parallel Postgres Servers, with the postmaster spawning off the
> >>server on a different node (possibly borrowing some code from GNU queue)
> >>and doing any buffer twiddling with RPC for that connection, The client
> >>connection would still be through the proxy on the postmaster node? (kind
> >>of like MOSIX)
> >
> >
> > One idea would be to throw parts of the executor (like a table sort) to
> > different machines or to different processors on the same machine,
> > perhaps via dblink. You could use threads to send several requests and
> > wait for their results.
> >
> > Threading the entire backend would be hard, but we could thread some
> > parts of it by having slave backends doing some of the work in parallel.
>
>
>
> This would be nice - especially for huge queries needed in warehouses.
> Maybe it could even make sense to do things in par. if there is just one
> machine (e.g. computing a function while a sort process is waiting for
> I/O or so).
>
> Which operations can run in par.? What do you think?
> I guess implementing something like that means 20 years more work on the
> planner ...
My guess is that we would have to have the user tell us which things
they want in parallel somehow. Of course, the child backend has to
parse/plan/execute the query, and pass the data up to the parent, so you
have to pick things where this overhead is acceptable.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073