Re: More grist for the PostgreSQL vs MySQL mill - Mailing list pgsql-general

From Shashank Tripathi
Subject Re: More grist for the PostgreSQL vs MySQL mill
Date
Msg-id 7cab9c1b0701211830x54a37981t77a0c5ef5e91334b@mail.gmail.com
Whole thread Raw
In response to Re: More grist for the PostgreSQL vs MySQL mill  ("Peter Rosenthal" <voiperster@gmail.com>)
Responses Re: More grist for the PostgreSQL vs MySQL mill  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: More grist for the PostgreSQL vs MySQL mill  (Chris <dmagick@gmail.com>)
Re: More grist for the PostgreSQL vs MySQL mill  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-general
> select something from othertable;
> select * from table where table_id in (?, ?, ?, ?, ?, ?, ?, ...)


This is what MySQL's CEO Martin said in an interview on Slashdot. If
we can manage two queries as above through, say, a PHP application,
with each executing in 0.004 seconds, then an optimized subquery needs
to be beat the 0.008 mark to be a viable alternative.

This works for most people who're not looking for elegance of database
design. I am assuming MYISAM engine with indexes on the WHERE columns.
Granted, this is neither future nor fool proof, but in high traffic
environments, it is all worth the drop in elegance.

The problem is when the number of rows exceeds 30 million, MySQL
performance degrades substantially. For most people, this is not an
issue. PG is solid with huge databases, but in my experience, even the
most optimized subselect on PG will not return a value in 0.008
seconds  on 10 million rows -- I'd appreciate other experiences.

Shanx

pgsql-general by date:

Previous
From: "Peter Rosenthal"
Date:
Subject: Re: More grist for the PostgreSQL vs MySQL mill
Next
From: Bruce Momjian
Date:
Subject: Re: documentation vs reality: template databases