Re: Need help in performance tuning.

On 10/07/10 00:56, Brad Nicholson wrote:
> On Fri, 2010-07-09 at 00:42 -0400, Tom Lane wrote:
>
>>
>> Perhaps not, but there's no obvious benefit either. Since there's
>> More Than One Way To Do It, it seems more practical to keep that as a
>> separate problem that can be solved by a choice of add-on packages.
>>
> This sounds similar to the approach to taken with Replication for years
> before being moved into core.
>
> Just like replication, pooling has different approaches. I do think
> that in both cases, having a solution that works, easily, out of the
> "box" will meet the needs of most users.
>
> There is also the issue of perception/adoption here as well. One of my
> colleagues mentioned that at PG East that he repeatedly heard people
> talking (negatively) about the over reliance on add-on packages to deal
> with core DB functionality.
>
>

It would be interesting to know more about what they thought an 'over
reliance' was and which packages they meant.

While clearly in the case of replication something needed to be done to
make it better and easier, it is not obvious that the situation with
connection pools is analogous. For instance we make extensive use of
PgBouncer, and it seems to do the job fine and is ridiculously easy to
install and setup. So would having (something like) this in core be an
improvement? Clearly if the 'in core' product is better then it is
desirable... similarly if the packaged product is better... well let's
have that then!

I've certainly observed a 'fear of package installation' on the part of
some folk, which is often a hangover from the 'Big IT shop' mentality
where it requires blood signatures and child sacrifice to get anything
new installed.

regards

Mark

P.s Also note that Database Vendors like pooling integrated in the core
of *their* product because it is another thing to charge a license for.
Unfortunately this can also become an entrenched mentality of 'must be
in core' on the part of consultants etc!