Re: Need help in performance tuning.

From: "Pierre C" <lists(at)peufeu(dot)com>
To: "Greg Smith" <greg(at)2ndquadrant(dot)com>, "Jesper Krogh" <jesper(at)krogh(dot)cc>
Cc: "Matthew Wakeling" <matthew(at)flymine(dot)org>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "Brad Nicholson" <bnichols(at)ca(dot)afilias(dot)info>, pgsql-performance(at)postgresql(dot)org, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Need help in performance tuning.
Date: 2010-07-11 22:47:05
Message-ID: op.vfpawrejeorkce@apollo13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> Two problems to recognize. First is that building something in has the
> potential to significantly limit use and therefore advancement of work
> on external pools, because of the "let's use the built in one instead of
> installing something extra" mentality. I'd rather have a great external
> project (which is what we have with pgBouncer) than a mediocre built-in
> one that becomes the preferred way just by nature of being in the core.

I would prefer having supplier A build a great product that seamlessly
interfaces with supplier B's great product, rather than having supplier M$
buy A, develop a half-working brain-dead version of B into A and market it
as the new hot stuff, sinking B in the process. Anyway, orthogonal feature
sets (like database and pooler) implemented in separate applications fit
the open source development model quite well I think. Merge everything in,
you get PHP.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Fujii Masao 2010-07-12 06:25:08 Re: Queries about PostgreSQL PITR
Previous Message Ryan Wexler 2010-07-11 20:02:50 Re: performance on new linux box