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
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 |
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 |