On Fri, Jun 7, 2013 at 2:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > "Fred&Dani&Pandora&Aquiles" <f...@nti.ufop.br> writes: >> I asked a while ago in this group about the possibility to implement a >> parallel planner in a multithread way, and the replies were that the >> proposed approach couldn't be implemented, because the postgres is not >> thread-safe. With the new feature Background Worker Processes, such >> implementation would be possible? > > I don't think that bgworkers as currently implemented make this any more > practical than it was before. The communication overhead with a > separate process would swamp any benefit in most cases.
I agree this can't be done yet, but I don't agree with that reasoning. I would articulate it this way: we don't have parallel execution, therefore how could we meaningfully do parallel optimization? I'm baffled by your statement that the communication overhead would be too high. What IPC mechanism are you presuming, and why would it be any more expensive in PostgreSQL than in any other database (a number of which do have parallel query execution)? -- 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
