Re: Parallel postgresql

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