Re: [OT] MySQL is bad, but THIS bad?

On 5/18/06, Jim C. Nasby <jnasby@pervasive.com> wrote:
> On Wed, May 17, 2006 at 09:35:34PM -0400, John DeSoi wrote:
> >
> > On May 17, 2006, at 8:08 PM, Mark Woodward wrote:
> >
> > >What is the best way to go about creating a "plug and play,"
> > >PostgreSQL
> > >replacement for MySQL? I think the biggest problem getting PostgreSQL
> > >accepted is that so much code is available for MySQL.
> >
> >
> > http://pgfoundry.org/projects/mysqlcompat/
>
> Even better would be coming up with a compatability mode, a la what
> EnterpriseDB has done for Oracle.

I don't think we actually want such a mode.  In theory it would be
great, but in practise... Especially from performance standpoint.

I mean, application for MySQL would usually be written as: quick
connect, do a query, disconnect.  No application-level caching, no
connection keep-alive.  First run on a similar hardware would be
a performance disaster. PostgreSQL connection initialisation
will be slower (yes, pgpool, but how much do you want to bet,
the reaction would be: "you said compatibility mode! no mention
of pgpool!"), and no caching would be noticable, to say the least.

I don't want to suggest adding caching to postgresql (I know it
isn't that great).  I want to suggest that MySQL users are used
to it and will be unhappy to part from it.

So, if you want to help people migrate to Postgres, better tell
them how to fix mysqlisms. I mean: "no replace into"? tell them
about create trigger on insert to handle duplicates.  No caching,
tell them about memcached and its advantages.  Tell how to
use pgpool.

Personally, I wish I had better knowledge of PostgreSQL years
back, when one project was started... I didn't know PostgreSQL
then, and well, MySQL outperformed it.  Of course when real
load was given, MyISAM were a performance disaster, but then
there was InnoDB...  And sometimes some developer will select
count(*) on InnoDB, and InnoDB will make a temporary table with
all the data, holding the lock on the table...  And sometimes the
replication will just break, and sometimes you need repair table.
All the usual fun. ;)

While I can talk to the DBAs and tell them about table partitioning,
PITR, MVCC, online backups, etc, etc. then add spice with PL/pgSQL
and other PL/*s the real problem is people are used to MySQL --
-- they know how to handle it, how to support it, what to expect
from it. The bigger the company, the harder it is to convince people
that they should start using something completely new. An important
application with 1 or 2 people who know what to do, when after a major
failure, restart doesn't help. This makes it very hard...

Personally my opinion is that there is no point in pushing PostgreSQL
everywhere -- if there is no siginifcant performance gain, most managers
will refuse it, on the grounds that "if it ain't (too) broke, don't fix it".
The real places to "attack at" are the BIG dbs, the dataware housing
applications.  Places where MySQL is not used, because someones
select count(*) should not kill the database.  Because the queries
take few hours to complete "by design". This should be doable. :)
  Regards,     Dawid