Skip site navigation (1) Skip section navigation (2)

[Fwd: MySQL Benchmark page - Problem with vacuum() in PostgreSQL]

From: Justin Clift <justin(at)postgresql(dot)org>
To: pgsql-general(at)postgresql(dot)org
Subject: [Fwd: MySQL Benchmark page - Problem with vacuum() in PostgreSQL]
Date: 2001-07-29 12:26:32
Message-ID: 3B6400F8.C44C45C2@postgresql.org (view raw or flat)
Thread:
Lists: pgsql-general
Hi all,

The "MySQL Benchmark" page on the mysql.com website has benchmarks for
various databases :

http://www.mysql.com/information/benchmarks.html

In the PostgreSQL entry they aren't able to report an "accurate" result
for all things, as they haven't been able to get vacuum to work 100%
correctly.

If someone can take a look at the description of the problem which Monty
is having (he's the lead MySQL developer) we'll be able to have accurate
benchmark for PostgreSQL on their benchmark page.

So, anyone want to lend a hand?

:-)

Regards and best wishes,

Justin Clift


-------- Original Message --------
Subject: MySQL Benchmark page - Problem with vacuum() in PostgreSQL
Date: Sat, 28 Jul 2001 14:01:22 +0200
From: Anna Ewerlid <Anna(dot)Ewerlid(at)signal(dot)uu(dot)se>
To: justin(at)postgresql(dot)org

Hi!

>>>>> "Justin" == Justin Clift <justin(at)postgresql(dot)org> writes:

Justin> Hi,
Justin> I'm looking at your MySQL benchmark page :

Justin> http://www.mysql.com/information/benchmarks.html

Justin> It says you guys weren't able to get vacuum() working reliably
with
Justin> PostgreSQL 7.1.1, and you'll generate a fast version of the
benchmarks
Justin> when you can.

Justin> What exactly was the problem?

I have tried to explain the problem in document that we have published
under the benchmarks results.

The problem was that when we run the benchmark with the --fast option,
which basicly does a vacuum() between after each batch of updates,
postmaster started to fill up disk with log files during one of the
vacuum() runs and didn't stop until the disk was full. When this
happened I killed postmaster and tried to restart it, but postmaster
just died with a core dump after that :(

I repeated the above a couple of times and was able to repeat the
problem with disk full, but didn't manage to crash postmaster again.

I would really appreciate if you could help us locate and fix the
problem is PostgreSQL, because I would really like to see that all
open source databases gets good benchmarks results to be able to
deliver the message that open source is a good alternative to
commercial databases.

If you have any time over, please take a look at the benchmarks and
see if there is anything that could be improved to get better results
for PostgreSQL, especially when running with the --fast option!

If you think we have missed any important 'single user' benchmark,
feel free to add it to the benchmark suite and email Anna and me a
patch; We really want to be able to show which operations are fast and
which are slow for the different databases, so that the different
database users know to which constructs they have to avoid!

We just hired Anna to start working on a multi-user benchmark suite
that will be a complement to the current single-user benchmark suite.

If you have any comments about the benchmarks, please share them with
us!
I have worked hard to make them fair against all databases;  I have
actually put more work into getting PostgreSQL to give good numbers
than for any other database!  The problem is that I don't know
PostgreSQL intimately which makes it a bit harder to get really
benchmark results for it!

Regards,
Monty

Responses

pgsql-general by date

Next:From: Ben-Nes MichaelDate: 2001-07-29 14:11:26
Subject: readline and rh7.1
Previous:From: Dave CramerDate: 2001-07-29 12:02:23
Subject: RE: getting nextval from query?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group