| 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: | Whole Thread | Raw Message | 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 |