From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, David Fetter <david(at)fetter(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL Advocacy List <pgsql-advocacy(at)postgresql(dot)org> |
Subject: | Re: Problem with recent PostgreSQL related pressrelease |
Date: | 2007-07-13 14:19:59 |
Message-ID: | 200707131419.l6DEJxQ19686@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy |
Andreas Pflug wrote:
> Simon Riggs wrote:
> >
> >> EnterpriseDB is 200% faster than an untuned PostgreSQL
> >>
> >
> > This sentence is true, even if it is a generalisation: the specific
> > workload tested was an OLTP workload. EnterpriseDB ships with a feature
> > called DynaTune that makes this so. My observation is that it does a
> > good job.
> >
> Please note that the website doesn't mention "untuned". We all know that
> an untuned PostgreSQL is usually slower than a tuned installation.
> Autotuning is a fine feature, but the EnterpriseDB website and marketing
> stuff gives the impression that the Enterprise _core_ system is 200 %
> better.
I did find that referenced here:
http://www.enterprisedb.com/downloads/datasheets/EnterpriseDB_Advanced_Server.pdf
EnterpriseDB substantially enhanced PostgreSQL, the world.s most
advanced open source database, to create the EnterpriseDB Database
Server. The product retains the legendary stability and reliability of
PostgreSQL while performing up to 200% faster.
Notice the marketing-twist "up to". Like, "save up to 99%" in a store window.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2007-07-13 14:40:32 | Re: Problem with recent PostgreSQL relatedpressrelease |
Previous Message | Bruce Momjian | 2007-07-13 14:12:44 | Re: Problem with recent PostgreSQL related pressrelease |