Re: Multithread Query Planner

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Multithread Query Planner
Дата
Msg-id CA+TgmoZuHdxiKy2z73PatQjHn1TtcT6fvU0JTTa5mZZLgkiWEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multithread Query Planner  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Multithread Query Planner  ("Pierre C" <lists@peufeu.com>)
Re: Multithread Query Planner  ("Fred&Dani&Pandora" <fred@nti.ufop.br>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Multithread Query Planner
Следующее
От: Robert Haas
Дата:
Сообщение: Re: lots of unused variable warnings in assert-free builds