Re: Pooling in Core WAS: Need help in performance tuning.

Sent from my iPhone

On Jul 9, 2010, at 18:25, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

>
> So while adding (b) to core alone would be very useful for some users,
> ironically it's generally for the more advanced users which are not
> the
> ones we're trying to help on this thread.

It would seem from evidence presented on this thread that the more
appropriate conversation would maybe be with package maintainers, to
perhaps get them to include a connection pool or provide a package
that comes with a pool preconfigured and installed, along with
improving existing documentation so that it encourages the use of a
pool as a first class installation choice since it seems to be
something of a first class problem for a lot of novice users.

Just to give some background on my perspective - my prior familiarity
with a connection pool was entirely on the client side, where I've
been using them for years go keep resource consumption down on the
client.. But it never occurred to me to consider one on the other end
of those connections, despite the fact that I usually have a cluster
of app hosts all talking to the same db. I assumed low connection
count was desirable, but not mandatory, since surely the db server
limited its own resource consumption, much the way a well written
client app will. I basically assumed that the postgres devs used the
same logic I did when I pooled my connections at the client side in
order to minimize resource consumption there. I've got no truck with
the reasons presented against doing so, since they make perfectly good
sense to me.

However, I suspect there are lots of engineers like myself - folks
working without the benefit of a dedicated dba or a dba who is new to
the postgres platform - who make naive assumptions that aren't
immediately or obviously corrected by the docs (I may be sticking my
foot in my mouth here. I haven't read the standard docs in a very long
time). With this issue in particular, the fix is fairly trivial and
brings other benefits as well. But it sucks to discover it only after
you've started to get errors on a running app, no matter how easy the
fix.

So probably this is really only a bug in communication and can be
fixed there. That's great. Easier to fix bugs are hard to find. I have
yet to contribute to postgres development, so I guess, if no one
objects, I'll see what I can do about improving the documentation of
this issue, both in the official docs and just making sure it gets
better billing in other sources of postgres documentation. But you'll
have to bear with me, as I do have a more-than-full-time other job,
and no experience with the pg developer community other than a couple
of weeks on the mailing lists. But I do like to contribute to projects
I use. It always winds up making me a more proficient user.

(for the record, if I wasn't limited to my phone at the moment I would
actually check the state of existing documentation before sending
this, so if I'm talking out of my ass on the lack of documentation,
please go easy on me. I mean no offense)

--sam

>