Re: PostgreSQL and Poker - Mailing list pgsql-general

From Scott Marlowe
Subject Re: PostgreSQL and Poker
Date
Msg-id dcc563d10907082151t6a23ac9aye039ec1b529684f4@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL and Poker  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-general
On Wed, Jul 8, 2009 at 10:05 PM, Greg Smith<gsmith@gregsmith.com> wrote:
> On Wed, 8 Jul 2009, Ivan Sergio Borgonovo wrote:
>
>> You can actually build up closed source software with MySQL as a
>> server, it depends on how you do it.
>
> I seriously doubt that:  http://www.mysql.com/about/legal/licensing/oem/
>
> The terms under which you can treat MySQL as a more open piece of software
> are pretty tightly constrained:
> http://www.mysql.com/about/legal/licensing/foss-exception/

Back in the day (v6.5.2) I picked pgsql because it had the features I
needed, good enough performance, fair stability (as good or better
than mysql's of the day) and that it didn't have mysql's restrictive
licensing.

Over time I think pgsql has come much further than mysql, and the
focus there has never been as clear as it is here, in terms of "don't
surprise the user in dangerous ways."  I think the mysql fanbois who
say these things in logs are usually just not at all familiar with
using pgsql on a daily basis.  Under any modern load, pgsql and mysql
are usually no more than +/- 30% or so in performance, unless you're
using a broken GA release like 5.0.x or so (whichever one tweakers
tested them on that it imploded on the Sun 32 thread CPU).   To be
fair, pgsql has had performance regressions show up, and some of them
take a few weeks to figure out.  But they're usually not as
catastrophic as the one that mysql had in that test.  So when I have
to use MySQL it's a small project / application that doesn't tax the
machine or the db.  Like internal ticketing maybe.  Whenever I think
"man, this might get really big or have thousands of hits per minute."
I want pgsql.  When I need to process and replicate 200 transactions
per second or more, I really want to use pgsql more than mysql.  I
know that between log shipping and slony I can guarantee downtimes in
the minutes during which things switch over, or are switched by hand,
than the possible hours involved should I have to restore from backup.

Mysql has come a long way, but the still somewhat loose adherence to
data integrity princples makes it a bad choice for important data.
Until there's a version that just runs on innodb and only innodb or
something like it, which has ALL the cool features (network db,
transactional db, full text indexing db) in one handler I don't want
to mess with it's sort of fits here, sort of fits there feature set.
I am happy about the companies that may be forking it.  It'd be nice
to have a pure GPL no commercial license version that runs on one
solid reliable table handler.  Or even allows me, the db to easily
pick which ones go where, so I don't have banking systems getting
built on myisam. I think that focusing on one good table handler in
postgresql has been a winning proposition so far.  That and release
discipline which has been pretty meh grade in the last few years for
mysql.

pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: c++ program to connect to postgre database
Next
From: Scott Marlowe
Date:
Subject: Re: ZFS prefetch considered evil?