Thread: Re: Problem with recent PostgreSQL relatedpressrel ease
> ------- Original Message ------- > From: "Joshua D. Drake" <jd@commandprompt.com> > To: "Joshua D. Drake" <jd@commandprompt.com> > Sent: 13/07/07, 22:10:59 > Subject: Re: [pgsql-advocacy] Problem with recent PostgreSQL relatedpressrelease > > Joshua D. Drake wrote: > > Dave Page wrote: > >> Joshua D. Drake wrote: > >>> Dave Page wrote: > > Regardless of this whole thread about CMD, it's not cool for a > company selling PostgreSQL support to be slagging PostgreSQL. > > Which was the point of the original post last night. No one from EDB can > legitimize that. No need to - no-one has been 'slagging PostgreSQL' - in fact we often pitch EDB as being based on PostgreSQL's rock-solidcode. In this case, it was stated that a customer would get better support, reliability and performance from EDB over their existingPostgreSQL system. I believe they're using AS81 - do you know what version of PostgreSQL they were using? 6.3.2?7.1? 8.0.4? Even if it were also 8.1, the performance gains are feasible, given DynaTune and other tweaks, and we maywell have found and fixed other bugs that aren't fixed in that PG version - we do have a buildfarm running something like17000 (iirc) regression tests nightly over the server *and* connectors. We also ship additional management tools, andreplication which the customer may be using to make their systems more reliable and fault tolerant. However you read that, it is not slagging PostgreSQL - heck, *I'd* be complaining to those responsible if that were the casebecause, like many other EDB staff, I consider myself part of the community, work primarily on community PG, and am veryproud of that fact. Regards, Dave
Dave Page wrote: > In this case, it was stated that a customer would get better support, reliability and performance from EDB over their existingPostgreSQL system. I believe they're using AS81 - do you know what version of PostgreSQL they were using? 6.3.2?7.1? 8.0.4? Even if it were also 8.1, the performance gains are feasible, given DynaTune and other tweaks, and we maywell have found and fixed other bugs that aren't fixed in that PG version - we do have a buildfarm running something like17000 (iirc) regression tests nightly over the server *and* connectors. We also ship additional management tools, andreplication which the customer may be using to make their systems more reliable and fault tolerant. I think the text makes it sound like this level of performance and stability was unattainable using PostgreSQL. What you could have said that this level of performance would be unattainable without manually tuning the database. I guess moving to EDB AS is an update to software, and they could as well updated to the latest PG version, so the staleness of their install does not count. Finally in regards to the comment about EDB AS having some features that are not yet in the stable version of PG, I guess the door swings both ways on that one? I mean there are bound to be some features making it into PG stable releases not yet in EDB AS? Then again I guess you will be very keen in quickly getting features into EDB AS that are of interest to your customers, however if you fast track features too much in EDB AS, you are bound to run into situations where your implementation will not be compatible with the PG implementation, since based on community feedback the implementation was changed. But if you already have a stable version out there with your implementation you will get into trouble. regards, Lukas