From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | Markus Schiltknecht <markus(at)bluegap(dot)ch>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support Parallel Query Execution in Executor |
Date: | 2006-04-11 17:20:19 |
Message-ID: | 20060411172019.GL11760@surnet.cl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Greg Stark wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-04-11 17:28:20 | Re: Support Parallel Query Execution in Executor |
Previous Message | Joshua D. Drake | 2006-04-11 17:19:55 | Re: RH9 postgresql 8.0.7 rpm |
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2006-04-11 17:28:20 | Re: Support Parallel Query Execution in Executor |
Previous Message | Greg Stark | 2006-04-11 17:15:33 | Re: Support Parallel Query Execution in Executor |