Re: Support Parallel Query Execution in Executor - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Support Parallel Query Execution in Executor
Date
Msg-id 877j5wj8l2.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: Support Parallel Query Execution in Executor  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Support Parallel Query Execution in Executor
List 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 by date:

Previous
From: Markus Schiltknecht
Date:
Subject: adding fields to pg_database
Next
From: Alvaro Herrera
Date:
Subject: Re: Support Parallel Query Execution in Executor