On 3 Oct 99, at 19:56, The Hermit Hacker wrote:
> On Sun, 3 Oct 1999, Paul DuBois wrote:
> > Well ... why don't you do that? While you're at it, if you can supply
> > more recent benchmarks for Postgres to the MySQL people, I doubt if they'd
> > refuse them. The benchmark page is meant to be helpful, not misleading
> > or a propaganda tool for MySQL.
> Actually, if you go through the PostgreSQL archives, there was *at least*
> one major attempt at getting the MySQL benchmark page upgraded...the
> thread involved the MySQL guys, and several of ours, and went on for a few
> days...if I recall it all correctly...
> ...end result...no changes :(
Yep that's true but I can't remember that we would update the
benchmark page. I thought we asked if you could help us with
updating the crash-me script (the discussion I believe was about
atomic updates). But lets don't start that discussion again. If you
will look now at the benchmark page you will see it will start with a
benchmark run between mysql and postgres (pg). It's done on
6.5.1 (saying 6.5 because it's from the file VERSION and I don't
know another way to get the version of pg) But I will run today the
benchmark on 6.5.2.
> The problem, as I see it, is how can you do a fair comparison when those
> features we'd use to improve performance, subselects to name one, aren't
> available in MySQL?
> What I'd love to see is a common set of data to work from, and table
> structures...then come up with, again, a common set of "results expected",
> from the database. Then, let the MySQL guys provide their query for the
> results, and let the PostgreSQL guys come up with theirs, and compare
> *that*. Don't compare how to get the results the fastest through MySQL,
> and then how the same query stands up under PostgreSQL...let us give them
> how to get it fastest from PostgreSQL...
> The problem also comes down to common hardware...
> Anyone out there running a machine, and have the time, to do something
> like this?
one year ago I copied the tpc d benchmark test and wrote it in perl.
I tested some things with it but because of the copyrights we can't
use it but maybe it's a good starting point to start developing a
benchmark for us. tpc benchmarks officially can't be done with
other queries then they have defined but we could keep that
restriction away. Allmost all queries are done in subselects / views
so there are a lot of things which can be tuned. For MySQL it will
be done in two or three queries but if the result is the same I think
it won't be a problem. For postgresql it will be possible I think to do
the querie at ones.
The easiest way I think will be to write the benchmark in perl with
the DBI / DBD module so it can be ported easily to maybe other
db's (like msql / solid / oracle / informix / sybase etc ...).
Eventually it could be added to the benchmark of MySQL so the
benchmark will be extended with some subselects and view tests.
By the way the wisconsin benchmark test is from the postgres
distribution only rewritten in perl with DBI/DBD module.
PS. maybe someone can forward this email to the postgres
mailinglist because I am not a member to the list.