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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
