Re: Support Parallel Query Execution in Executor

Alvaro Herrera  writes:

> Greg Stark wrote:
> > Alvaro Herrera  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