On Tue, Oct 4, 2011 at 10:55 PM, Greg Stark <st...@mit.edu> wrote: > I agree that if we wanted to farm out entire plan nodes we would > probably end up generating new partial plans which would be handed to > other backend processes. That's not unlike what Oracle did with > Parallel Query. But i'm a bit skeptical that we'll get much of that > done in 2-3 years. The main use case for Parallel Query in Oracle is > for partitioned tables -- and we haven't really polished that after > how many years?
Partitioning hasn't been completely neglected; 9.1 adds support for something called Merge Append. You may have heard of (or, err, authored) that particular bit of functionality. :-) Of course, it would be nice to have a better syntax, but I don't think the lack of it should discourage us from working on parallel query, which is a muti-part problem. You need to: - have planner support to decide when to parallelize - have a mechanism for firing up worker processes and synchronizing the relevant bits of state between the master and the workers - have an IPC mechanism for streaming data between the master process and the workers - figure out how to structure the executor so that the workers neither stall nor run too far ahead of the master (which might have LIMIT 10 or something) Markus Wanner took a crack at generalizing the autovacuum machinery that we have now into something that could be used to fire up general-purpose worker processes, but it fell down mostly because I (and, I think, others) weren't convinced that imessages were something we wanted to suck into core, and Markus reasonably enough wasn't interested in rewriting it to do something that wouldn't really help his work with Postgres-R. I'm not sure where Bruce is getting his timeline from, but I think the limiting factor is not so much that we don't have people who can write the code as that those people are busy, and this is a big project. But you can bet that if it gets to the top of Tom's priority list (just for example) we'll see some motion...! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers