Re: Support Parallel Query Execution in Executor

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Support Parallel Query Execution in Executor
Дата
Msg-id 20060411204948.GU49405@pervasive.com
обсуждение исходный текст
Ответ на Re: Support Parallel Query Execution in Executor  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
Список pgsql-hackers
On Mon, Apr 10, 2006 at 05:22:13PM +0800, Qingqing Zhou wrote:
> 
> "Markus Schiltknecht" <markus@bluegap.ch> wrote
> > Hi Qingqing,
> >
> > >
> > > 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?
> >
> Check the code InitPostgres(). These global varaibles are scattered in many
> places, so I am not sure if it is easy to write clean code to clear up these
> variables. But if you can come up with a patch to do reconnect without
> disconnect, that will be cool.

Something else to consider: most queries that would benefit from
parallel execution are expensive enough that the cost of spawning some
new backends wouldn't be that big a deal, so perhaps for an initial
version it would be best to KISS and just spawn parallel execution
backends as needed.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: OS cached buffers (was: Support Parallel Query Execution in Executor)
Следующее
От: David Fetter
Дата:
Сообщение: Re: plpgsql by default