From: | Kirk Strauser <kirk(at)strauser(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Why would I want to use connection pooling middleware? |
Date: | 2009-01-15 16:26:35 |
Message-ID: | 8F542701-5747-40AB-A63A-312F8185EFCD@strauser.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Jan 15, 2009, at 10:08 AM, Tom Lane wrote:
> As an example, any system catalog update has to be broadcast to all
> live backends, and they all have to dutifully search their catalog
> caches to flush stale entries. That costs the same whether the
> backend is being put to use or has been sitting idle for minutes.
I didn't realize that. I wasn't sure what types of overheads were
involved and didn't think about those sorts of things.
> There's no percentage in trying to pool connections from applications
> that are constantly doing something; but webserver sessions tend to
> have
> lots of user "think time" as well as similar DB environments, so often
> they can be pooled profitably.
That makes sense. Along those lines, how do you actually enable
connection pooling in pgpool-II? I've RTFM a few times but it doesn't
seem to have a flag for "enable_pooling". Is "num_init_children"
effectively the same as a hypothetical "max_children?" If I set it to
"1" and leave "max_pool" at "4", then clients queue up while one at a
time gets to connect.
Sorry, I know this isn't the pgpool-II mailing list. :-)
--
Kirk Strauser
From | Date | Subject | |
---|---|---|---|
Next Message | Guy Rouillier | 2009-01-15 16:57:13 | Re: Why would I want to use connection pooling middleware? |
Previous Message | Bill Moran | 2009-01-15 16:20:51 | Re: Why would I want to use connection pooling middleware? |