>>>- Define a 32-bit field in MySQL. Insert a 64-bit number instead.
>>>Common sense tells you the value would be rejected. Yet MySQL happily
>>>folds it in and carries on its merry way.
>>
>> That's unacceptable. To me, this is a complete show-stopper because I
>> simply won't tolerate data loss due to an idiotic design flaw.
>
> Worse. It is no data loss. It is loss of data integrity. If I know I
> have lost two hours of work, I will crib but redo it. If I know around
> 5% of records are messed up by database in last 5 years but don't know
> which, just think where do I stand.
That is worse, thanks for your clarity. I stopped before thinking it
through this far because any kind of screw-up like this just isn't worth
the risk in my opinion -- they really need to fix that and I think they
should make it a high priority.
[sNip]
>> Do you know of any published benchmarks for this? I need to convince
>> some people who are hell-bent on MySQL being fast for everything that
>> they're mis-informed, and they refuse to take anyone's word for it.
>
> Good benchmarks are hard to come by for two reasons
>
> 1. It is very difficult not to be blamed biased.
> 2. Featuer compensation. What if you run a postgresql benchmark with
> triggers and views, how do you test it with mysql anyways?
>
> I would suggest you to try OSDB becnhmarks
>
> http://osdb.sourceforge.net/
Thanks, I'll take a look at that.
> Your results will be great contribution to the community.
If I get enough spare time, I'll consider doing this.
> Or try porting pgbench to mysql innodb.
>
> Actually I would like to see what the this benchmark does. Any prior
> knowledge of the results?
I have no idea.
[sNip]
>> I've experienced this very problem with MySQL actually. It seems that
>> Apache James (an open source Java-based SMTP/POP3 mail server) running
>> on FreeBSD will trigger this problem very quickly as soon as multiple
>> users attempt to send large (greater than 10 MBs) file attachments --
>> perhaps JDBC is part of the problem, but in the Apache James error logs
>> there is indication of MySQL connectivity problems (also during busy
>> times on systems sending approximately 500,000 eMails per day).
>
> Try dbmail. I am no mail admin but that is a mail server which works off
> postgresql/mysql. http://www.dbmail.org
I see that it doesn't support file-based mail directories for storing
messages. That's too bad, because it just won't be able to meet the
performance of well-programmed mail servers such as Mercury (uses Novell
Directory Services for the user database) or qmail (can use PostgreSQL, and
other database engines, for the user database).
--
Randolf Richardson - rr@8x.ca
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
http://www.8x.ca/
This message originated from within a secure, reliable,
high-performance network ... a Novell NetWare network.
