Re: Multithread Query Planner - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Multithread Query Planner
Date
Msg-id CA+TgmoZuHdxiKy2z73PatQjHn1TtcT6fvU0JTTa5mZZLgkiWEg@mail.gmail.com
Whole thread Raw
In response to Re: Multithread Query Planner  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multithread Query Planner  ("Pierre C" <lists@peufeu.com>)
Re: Multithread Query Planner  ("Fred&Dani&Pandora" <fred@nti.ufop.br>)
List pgsql-hackers
On Tue, Jan 24, 2012 at 11:25 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> I doubt it.  Almost nothing in the backend is thread-safe.  You can't
>> acquire a heavyweight lock, a lightweight lock, or a spinlock. You
>> can't do anything that might elog() or ereport().  None of those
>> things are reentrant.
>
> Not to mention palloc, another extremely fundamental and non-reentrant
> subsystem.
>
> Possibly we could work on making all that stuff re-entrant, but it would
> be a huge amount of work for a distant and uncertain payoff.

Right.  I think it makes more sense to try to get parallelism working
first with the infrastructure we have.  Converting to use threading,
if we ever do it at all, should be something we view as a later
performance optimization.  But I suspect we won't want to do it
anyway; I think there will be easier ways to get where we want to be.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Multithread Query Planner
Next
From: Robert Haas
Date:
Subject: Re: lots of unused variable warnings in assert-free builds