Re: Support Parallel Query Execution in Executor

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
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:15:33
Message-ID: 87irpgjaoa.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

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?

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2006-04-11 17:19:55 Re: RH9 postgresql 8.0.7 rpm
Previous Message Joshua D. Drake 2006-04-11 16:46:47 Re: plpgsql by default

Browse pgsql-patches by date

  From Date Subject
Next Message Alvaro Herrera 2006-04-11 17:20:19 Re: Support Parallel Query Execution in Executor
Previous Message Bruce Momjian 2006-04-11 16:42:23 Re: Patch proposal for log_duration