Thread: Another "benchmark" of MySQL/PostgreSQL on MySQL maillist

Another "benchmark" of MySQL/PostgreSQL on MySQL maillist

From
Alexey Borzov
Date:
Hi!

Here it is:
http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho

I already asked the author whether he tried to reasonably tune
PostgreSQL before benchmarking. It will be good if some "official"
PostgreSQL folks help with the discussion.

I think that if the author of the "benchmark" really wants to get decent
performance (and not to bash Postgres) then he will re-run the stuff.
And that's a good possibility to show MySQL users the real performance
situation --- and in their own maillist. ;


Re: Another "benchmark" of MySQL/PostgreSQL on MySQL maillist

From
"Shridhar Daithankar"
Date:
On 15 Jul 2003 at 13:29, Alexey Borzov wrote:

> Hi!
>
> Here it is:
> http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho
>
> I already asked the author whether he tried to reasonably tune
> PostgreSQL before benchmarking. It will be good if some "official"
> PostgreSQL folks help with the discussion.

Well, yes. Ask him to come over to performance list, if he cares. I doubt that
looking at the entire thread. Only couple of sensible postings with a benchmark
page at http://www.sergeant.org/sqlite_vs_pgsync.html for which I couldn't find
postgresql.conf file. Furthermore sqllite results do not agree with
http://www.sqlite.org/speed.html in themselves..

> I think that if the author of the "benchmark" really wants to get decent
> performance (and not to bash Postgres) then he will re-run the stuff.
> And that's a good possibility to show MySQL users the real performance
> situation --- and in their own maillist. ;

I won't be too optimistic about that. But worth a try..

Bye
 Shridhar

--
bit, n:    A unit of measure applied to color.  Twenty-four-bit color    refers to
expensive $3 color as opposed to the cheaper 25    cent, or two-bit, color that
use to be available a few years ago.


Re: Another "benchmark" of MySQL/PostgreSQL on

From
Robert Treat
Date:
On Tue, 2003-07-15 at 05:55, Shridhar Daithankar wrote:
> On 15 Jul 2003 at 13:29, Alexey Borzov wrote:
>
> > Hi!
> >
> > Here it is:
> > http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho
> >
> > I already asked the author whether he tried to reasonably tune
> > PostgreSQL before benchmarking. It will be good if some "official"
> > PostgreSQL folks help with the discussion.
>
> Well, yes. Ask him to come over to performance list, if he cares. I doubt that
> looking at the entire thread. Only couple of sensible postings with a benchmark
> page at http://www.sergeant.org/sqlite_vs_pgsync.html for which I couldn't find
> postgresql.conf file. Furthermore sqllite results do not agree with
> http://www.sqlite.org/speed.html in themselves..
>

Actually that page is interesting as much for the things it leaves out.
It compares pgsql and sql lite in a async mode and fsync mode.  It gives
some explanation on why the fsync mode is so much slower for sql lit,
but it seems to overlook that postgresql also can turn fsync on or off
(the default is on, which would slow postgresql down). Also I noticed
that these test were run against postgresql 7.1.3, which is a bit
outdated. Even tuned you'd have to expect it to perform slower than
7.3.3.  The other thing there seems to be no mention of is whether there
were ever any vacuum/analyze performed. In some of these tests that
would be a pretty important factor (like between the two 25,000 update
tests)

> > I think that if the author of the "benchmark" really wants to get decent
> > performance (and not to bash Postgres) then he will re-run the stuff.
> > And that's a good possibility to show MySQL users the real performance
> > situation --- and in their own maillist. ;
>
> I won't be too optimistic about that. But worth a try..
>

It's worth noting that the original poster was not the sqlite benchmark
guy. Since the sqlite test is publicly available, I think you could run
it against a more recent, tuned version and the author probably would
accept it. In the end though I'd expect sqlite to be faster, it has a
narrow feature set and specific scope, and we probably can't scale down
to that level. (For sure we scale up higher, but that's not whats being
measured.  As for the original poster, unless he shows up on
-performance I think his mind is already made up.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


Re: Another "benchmark" of MySQL/PostgreSQL on

From
Alexey Borzov
Date:
Hi!

Robert Treat wrote:

> It's worth noting that the original poster was not the sqlite benchmark
> guy. Since the sqlite test is publicly available, I think you could run
> it against a more recent, tuned version and the author probably would
> accept it. In the end though I'd expect sqlite to be faster, it has a
> narrow feature set and specific scope, and we probably can't scale down
> to that level.

I don't think it's a good idea to try to compete with SQLite... Due to
its limitations (locking the whole file representing a database on
INSERT/UPDATE) it will go belly-up quite fast in the case of concurrent
write access.

The reason I posted the link for this benchmark to MySQL maillist is not
because I am perfectly happy with it, but because it clearly shows the
difference between default and tuned PostgreSQL and claims that tuned
PostgreSQL is as fast as MySQL with MyISAM (the original poster was
using InnoDB, which is most probably slower)

> (For sure we scale up higher, but that's not whats being
> measured.  As for the original poster, unless he shows up on
> -performance I think his mind is already made up.

Yes, the guy does sound like a cheerleader. Let's see if he answers
anything...



Re: Another "benchmark" of MySQL/PostgreSQL on

From
"scott.marlowe"
Date:
On Tue, 15 Jul 2003, Alexey Borzov wrote:

> Hi!
>
> Here it is:
> http://lists.mysql.com/list.php?1:mss:145114:mbnfmalgopgpdmpooeho
>
> I already asked the author whether he tried to reasonably tune
> PostgreSQL before benchmarking. It will be good if some "official"
> PostgreSQL folks help with the discussion.
>
> I think that if the author of the "benchmark" really wants to get decent
> performance (and not to bash Postgres) then he will re-run the stuff.
> And that's a good possibility to show MySQL users the real performance
> situation --- and in their own maillist. ;

Invariably, what's happened is they've written code full of

select max(id) from table_of_a_million_records

or

select * from table where id in (list_of_1000_ids)

or they are trying to insert 10,000 rows but not bothering to put them in
a transaction.

Add to that the fact that 99% of these folks have NOT bothered to
optimize the postgresql.conf file or the OS they're running on and it just
gets worse.

Most of the time, it's a simple case of not taking to time to learn the
way to do things fast in the newer database.

the funny thing is, as MySQL adds these features, it WILL slow down.  then
the users who wanted triggers / views etc... will find themselves with the
same problems in MySQL they are complaining about in Postgresql.  I.e.
they'll have to learn the workarounds to make things faster.

As an engineer, I value stability and reliability first, since MySQL seems
to be missing those qualities, it's not even in the running for me.


Re: Another "benchmark" of MySQL/PostgreSQL on

From
Dennis Björklund
Date:
On Tue, 15 Jul 2003, Shridhar Daithankar wrote:

> Well, yes. Ask him to come over to performance list,

Did he get an invitation by anyone?

To ask him and tell him that we would like to know more about his problem
would hopefuly be enought. Then we can either help him fix the speed issue
or at least understand why it is slow in pg. He should be interested in
that (I hope).

--
/Dennis