Re: Article on MySQL vs. Postgres - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: Article on MySQL vs. Postgres
Date
Msg-id Pine.BSF.4.21.0007042323400.33627-100000@thelab.hub.org
Whole thread Raw
In response to Article on MySQL vs. Postgres  (Tim Perdue <tperdue@valinux.com>)
List pgsql-hackers
On Tue, 4 Jul 2000, Tim Perdue wrote:

> Performace/Scalability:
> 
> MySQL was About 50-60% faster in real-world web serving, but it
> crumbles under a real load. Postgres on the other hand scaled 3x
> higher than MySQL before it started to crumble on the same machine.
> Unfortunately, Postgres would probably still lose on a high-traffic
> website because MySQL can crank out the pages so much faster
Actually, this one depends alot on how the site is
setup/programmed.  I did work with a friend several months ago using the
newest released versions of MySQL and PostgreSQL ... we loaded (with some
massaging) the exact same data/tables onto both on the *exact* same
machine, and the exact same operating system.  When we ran their existing
web site, without modifications, on both MySQL and PgSQL, the MySQL was
substantially faster ... when we spent a little bit of time looking at the
queries used, we found that due to MySQLs lack of sub-queries, each page
being loaded had to do multiple queries to get the same information that
we could get out of PgSQL using one.  Once we optimized the queries, our
timings to load the page went from something like 3sec for MySQL and 1sec
for PgSQL ... (vs something like, if I recall correctly, 19sec for
PgSQL) ...
Same with some recent work I did with UDMSearch ... by default,
UDMSearch does 2+n queries to the database to get the information it
requires ... by re-writing the 'n' queries that are performed as an IN
query, I was able to cut down searches from taking ~1sec*n queries down to
a 3sec query ...
The point being that if you do a 1:1 comparison, MySQL will be
faster ... if you use features in PgSQL that don't exist in MySQL, you can
knock that speed difference down considerably, if not surpass MySQL,
depending on the circumstance ...




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Repair plan for inet and cidr types
Next
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql/doc/TODO.detail (alpha default distinct flock fsync function limit null pg_shadow primary)