On Fri, Jun 7, 2013 at 2:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Fred&Dani&Pandora&Aquiles" <fred@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
parallelexecution,
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