Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group