Re: Performance (was: The New Slashdot Setup (includes MySql server))

From: Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu>
To: Matthias Urlichs <smurf(at)noris(dot)net>
Cc: The Hermit Hacker <scrappy(at)hub(dot)org>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Hannu Krosing <hannu(at)tm(dot)ee>, Alessio Bragadini <alessio(at)albourne(dot)com>, pgsql-hackers(at)postgresql(dot)org, Chris <chris(at)bitmead(dot)com>
Subject: Re: Performance (was: The New Slashdot Setup (includes MySql server))
Date: 2000-05-20 01:53:28
Message-ID: 3925F018.14A8913A@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

> The MySQL people probably didn't dig deeper into PostgreSQL's innards.
> They don't seem to think it's their job to find out exactly why their
> benchmark runs so slow on some other databases, and I don't particularly
> fault them for that attitude.

Hmm. And then who's job is it to take someone else's work and make it
accurate? If the shoe were on the other foot: if I generated a
benchmark suite and features list, and it contained major and numerous
inaccuracies, who would you expect to be responsible (or at least feel
responsible) for correcting/updating/improving it? 'Twould be me imho.

We've tried, and failed (to date) to contribute information to the
"crashme" travesty. My recollection was a ~30% error rate on
information for Postgres, and I didn't look into the stats for other
databases. Check the archives for details.

> The PostgreSQL community has an attitude too, after all.

Yup ;)

> One of these might be to answer "you must have had fsync turned on"
> whenever somebody reports a way-too-slow benchmark. In this case,
> that's definitely not true.

I'm sorry that has been your experience. imho, that initial response
might be considered "helpful advice", not "attitude". And I'll submit
that most postings I've seen (I'm mostly on the -hackers list) are
followed up to the bitter end if the poster can state the problem
succinctly and can follow up with specific information. But I'm a
developer, so don't have the right outlook.

> Anyway, I fully expect to have a more reasonable benchmark result by
> tomorrow, and the MySQL guys will get a documentation update. Which they
> _will_ put in the next update's documentation file. Trust me. ;-)

Fantastic! We've been down this road before, and have had little luck
in getting more than a token update of inaccuracies. Any little bit
helps.

And while you're at it, can you update their docs and web site to make
clear that transactions and atomicity are not anywhere near the
feature list of MySQL yet? TIA

- Thomas

--
Thomas Lockhart lockhart(at)alumni(dot)caltech(dot)edu
South Pasadena, California

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael A. Mayo 2000-05-20 05:08:13 Columns in pg_shadow?
Previous Message Bruce Momjian 2000-05-20 01:46:43 Re: Performance (was: The New Slashdot Setup (includes MySql server))

Browse pgsql-hackers by date

  From Date Subject
Next Message Mike Mascari 2000-05-20 03:53:51 Postgres Analysis Tool-Pak
Previous Message Bruce Momjian 2000-05-20 01:46:43 Re: Performance (was: The New Slashdot Setup (includes MySql server))