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.
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 |