Re: [Sqlgrey-users] warn_if_reject to populate the db

[Lionel B. <lio...@bo...>]

Michel Bouissou wrote the following on 30.06.2005 09:08 :

>Le Mardi 28 Juin 2005 16:05, Lionel Bouton a =E9crit :
> =20
>
>>>BTW, why state that MySQL is a poor choice ?
>>>     =20
>>>
>>It's often buggy and doesn't follow the standard ?
>>   =20
>>
>
>I didn't use MySQL until a few weeks ago, so I couldn't tell for older=20
>versions, but MySQL 4.1.12 seems to work perfectly for me.
>
>And it's 15 times faster (!!!) than PostgreSQL for the very DB-intensive=
 DSPAM=20
>(this nice crowd of bugs ;-)
> =20
>

DSPAM is a special case. I've had a quick look into its backend drivers:
they use proprietary features of MySQL to speed things up. Their
PostgreSQL driver is known to be less worked on too.

For pure *transactional* (MySQL's MyISAM tables aren't in the same
competitive field) SQL, MySQL and PostgreSQL are roughly at the same
performance level although PostgreSQL is often reported to scale better
under concurrent accesses.

On the stability front, of all the database admins I've had personnal
contacts with, only the MySQL ones witnessed crashes (and chronic ones
at that) and data loss not related to hardware failures. It was each
time on heavily loaded, very big databases (tables in the GB or tens of
GB range), running on multiple CPUs...
The stability seems better since 6 months ago in the 4.1.x branch tough.
But for 6 years I've personnaly worked with PostgreSQL in various kinds
of loads and queries, I've *never* had a crash. In fact I've a
PostgreSQL 7.2 server in production for 3 years now with around 500 days
of uptime, which is the time since the last kernel upgrade (I don't know
the exact uptime as it wrapped at around 450 days and now shows 42 days
:-) ) hosting 10 databases with a total constant load around 10
queries/second.

In the quirkiness department, in SQLgrey, setting aside the now()
function declaration for SQLite, although I originally developped
SQLgrey with MySQL, all the special cases are for it, from the top of my
head:
- the "I update the timestamp because I think it's better for you" bugfix=
,
- the need to tell the client to autoreconnect because the server drops
the connection without being told to,
- the heavy SQL involved with timestamp differences.

The first two introduced bugs in SQLgrey, the last one made me spent
quite some time looking for a working SQL syntax...

>15 times faster, that was a good reason for me to migrate...
> =20
>

<OT> Yep. In my case, the lack of performance is one reason I consider
evaluating other statistical filters. Even with MySQL, DSPAM doesn't
seem to scale well enough for thousands of users. Too bad, DSPAM comes
with a nice web interface out of the box. I'll have to do some php/perl
web hacking and I lack time for this :-(</OT>

Lionel.