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

From: "Matthias Urlichs" <smurf(at)noris(dot)net>
To: The Hermit Hacker <scrappy(at)hub(dot)org>
Cc: Matthias Urlichs <smurf(at)noris(dot)net>, 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-19 14:00:14
Message-ID: 20000519160014.X27730@noris.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Hi,

The Hermit Hacker:
> > Thanks, everybody. The first quick benchmark run I did afterwards states
> > that PostgreSQL is now only half as fast as MySQL, instead of the factor
> > of 30 seen previously, on the MySQL benchmark test. ;-)
>
> Wow, shock of shocks ... MySQL has more inaccuracies in their docs? *grin*

No, that factor of 30 was my result after running the benchmark for the
first time. Presumably, unless I skip the large_number_of_tables test,
it'll be just as slow the second time around.

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.

The PostgreSQL community has an attitude too, after all.

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.

Another attitude of the PostgreSQL developers might be to answer "run
VACUUM" whenever somebody reports performance problems. That answer is
not helpful at all WRT this benchmark, because the user who caused the
problem ("test", in my case) isn't permitted to run VACUUM on the
pg_index table.

The alternate solution would be for the backend to notice "Gee, I just
scanned a whole heap of what turned out to be empty space in this here
pg_index file, maybe it would be a good idea call vacuum() on it."

Or, if that doesn't work, increase the buffer for holding its content.

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. ;-)

--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
"The so-called Christian world is contracepting itself out of existence."
-- Fr. L. Kieffer, HLI Reports, August 1989, as quoted in "The Far
Right, Speaking For Themselves," a Planned Parenthood pamphlet

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message The Hermit Hacker 2000-05-19 14:16:34 Re: OO Patch
Previous Message Tom Lane 2000-05-19 13:58:14 Re: Does Order by support case?

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2000-05-19 14:05:16 Re: Re: [SQL] Foreign keys breaks tables permissions
Previous Message Mitch Vincent 2000-05-19 13:47:39 Re: Performance (was: The New Slashdot Setup (includes MySql server))