[Fwd: Re: [GENERAL] PostgreSQL vs. InnoDB performance] - Mailing list pgsql-advocacy

From Ned Lilly
Subject [Fwd: Re: [GENERAL] PostgreSQL vs. InnoDB performance]
Date
Msg-id 42A04FFC.1010302@nedscape.com
Whole thread Raw
List pgsql-advocacy
Forwarding Peter's MySQL report from -general to -advocacy.  My jaw dropped when I saw this:


-------- Original Message --------
Subject: Re: [GENERAL] PostgreSQL vs. InnoDB performance
Date: Fri, 3 Jun 2005 11:38:28 +0200
From: Peter Eisentraut <peter_e@gmx.net>
To: pgsql-general@postgresql.org
References: <200506030036.29844.peter_e@gmx.net>

Am Freitag, 3. Juni 2005 00:36 schrieb Peter Eisentraut:
> On a particular system, loading 1 million rows (100 bytes, nothing
> fancy) into PostgreSQL one transaction at a time takes about 90
> minutes.  Doing the same in MySQL/InnoDB takes about 3 minutes.  InnoDB
> is supposed to have a similar level of functionality as far as the
> storage manager is concerned, so I'm puzzled about how this can be.
> Does anyone know whether InnoDB is taking some kind of questionable
> shortcuts it doesn't tell me about?

So here's another little gem about our friends from Uppsala: If you create a
table with InnoDB storage and your server does not have InnoDB configured, it
falls back to MyISAM without telling you.

As it turns out, the test done with PostgreSQL vs. real InnoDB results in just
about identical timings (90 min).  The test done using PostgreSQL with fsync
off vs. MyISAM also results in about identical timings (3 min).  So that
looks much better, although the update performance of PostgreSQL is still a
lot worse.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)




pgsql-advocacy by date:

Previous
From: Andreas Pflug
Date:
Subject: EnterpriseDB/pgAdmin status
Next
From: Bruce Momjian
Date:
Subject: Involvement of Unisys