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 87irpgjaoa.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  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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?


-- 
greg



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: plpgsql by default
Next
From: "Joshua D. Drake"
Date:
Subject: Re: RH9 postgresql 8.0.7 rpm