Re: Multithread Query Planner

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Christopher Browne <cbbrowne(at)gmail(dot)com>, Frederico <zepfred(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Multithread Query Planner
Date: 2012-01-24 16:29:04
Message-ID: CA+TgmoZuHdxiKy2z73PatQjHn1TtcT6fvU0JTTa5mZZLgkiWEg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 24, 2012 at 11:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-01-24 16:52:33 Re: lots of unused variable warnings in assert-free builds
Previous Message Tom Lane 2012-01-24 16:25:59 Re: Multithread Query Planner