On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing <hannu@xxxxxxxxxxx> wrote: > On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote: >> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing <hannu@xxxxxxxxxxx> wrote: >> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote: >> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer >> >> <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: >> >> > So rather than asking "should core have a connection pool" perhaps >> >> > what's needed is to ask "what can an in-core pool do that an external >> >> > pool cannot do?" >> >> >> >> Avoid sending every connection through an extra hop. >> > >> > not really. in-core != magically-in-right-backend-process >> >> Well, how about if we arrange it so it IS in the right backend >> process? I don't believe magic is required. > > Do you have any design in mind, how you can make it so ? Well, if we could change the backends so that they could fully reinitialize themselves (disconnect from a database to which they are bound, etc.), I don't see why we couldn't use the Apache approach. There's a danger of memory leaks but that's why Apache has MaxRequestsPerChild, and it works pretty darn well. Of course, passing file descriptors would be even nicer (you could pass the connection off to a child that was already bound to the correct database, perhaps) but has pointed out more than once, that's not portable. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
