Re: Support Parallel Query Execution in Executor

From: Markus Schiltknecht <markus(at)bluegap(dot)ch>
To: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Support Parallel Query Execution in Executor
Date: 2006-04-10 10:39:41
Message-ID: 1144665581.32238.21.camel@fotomarburg
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hi Qingqing,

On Mon, 2006-04-10 at 16:38 +0800, Qingqing Zhou wrote:
> > Why not? What would be needed to retarget a backend to operate in
> > another database?
>
> As Tom pointed out, without big change, a backend on database "D1" can't
> connect to "D2". This is because to connect to a database, we need to
> initialize a lot of variables. So when you reconnect to another one on the
> fly, you have to change these variables one by one.

Sure, the question is: what is needed to retarget a backend?

IMHO, in all of the three examples mentioned up-thread, it would be
better to retarget an existing backend, instead of forking a new one,
because that would perform better and/or save some resources.

Please do also consider, that for parallel query execution as well as
for replaying remote transactions access rights checking and any client
connection setup could be omitted. Such special processing backeds could
easily be run with superuser privileges and without a client connection.

Regards

Markus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Schiltknecht 2006-04-10 11:11:08 Re: Support Parallel Query Execution in Executor
Previous Message Markus Schiltknecht 2006-04-10 10:02:31 Re: Support Parallel Query Execution in Executor

Browse pgsql-patches by date

  From Date Subject
Next Message Markus Schiltknecht 2006-04-10 11:11:08 Re: Support Parallel Query Execution in Executor
Previous Message Markus Schiltknecht 2006-04-10 10:02:31 Re: Support Parallel Query Execution in Executor