Re: Support Parallel Query Execution in Executor

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Support Parallel Query Execution in Executor
Дата
Msg-id 877j5wj8l2.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: Support Parallel Query Execution in Executor  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: Support Parallel Query Execution in Executor  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:

> Greg Stark wrote:
> > Alvaro Herrera <alvherre@commandprompt.com> writes:
> > 
> > > An idea arising in chat with Joshua Drake:  the retargetting code, if it
> > > turns out to work and not be excessively expensive, could also be useful
> > > to implement a server-side "connection pooling" of sorts: the postmaster
> > > could keep idle backends and retarget them to a database that receives
> > > an incoming connection.  However, we'd also need a mechanism to clean
> > > all backend state previous to reusing a connection, to leave it "as
> > > new" (no prepared statements, WITH HOLD cursors, etc.)
> > 
> > Isn't all that work pretty much exactly the main cost of starting a new
> > backend?
> 
> On Linux and other systems were fork() has negligible cost, maybe; but
> on Windows and Solaris, it's certainly not.

Even on Solaris I'm sure parsing and preparing plans for all the queries,
building up the system table cache for all the objects in the database, and so
on are much much more expensive than fork(). I wouldn't be surprised if even
on windows it was still a pretty close race.

-- 
greg



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

Предыдущее
От: Markus Schiltknecht
Дата:
Сообщение: adding fields to pg_database
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Support Parallel Query Execution in Executor