Hi,
Thomas Lockhart:
>
> Hmm. And then who's job is it to take someone else's work and make it
> accurate? If the shoe were on the other foot: if I generated a
> benchmark suite and features list, and it contained major and numerous
> inaccuracies, who would you expect to be responsible (or at least feel
> responsible) for correcting/updating/improving it? 'Twould be me imho.
>
Umm, there's still a difference between saying (a) "it's broken, fix
it", (b) "here's my analysis as to what exactly is broken, can you fix
it", and (c) "here's a patch that fixes it".
I get the distinct impression that most of the communication between the
PostgreSQL and MySQL people has been looking more like (a) in the
past... if I can help both projects by doing some "translation" towards
(b) and (c), if at all possible, then so much the better.
> We've tried, and failed (to date) to contribute information to the
> "crashme" travesty. My recollection was a ~30% error rate on
> information for Postgres, and I didn't look into the stats for other
> databases. Check the archives for details.
>
Attached is the current crashme output. "crash_me_safe" is off only
because of the fact that some tests go beyond available memory.
There's no sense in testing how far you can push a "SELECT a from b where
c = 'xxx(several megabytes worth of Xes)'" query when the size fo a TEXT
field is limited to 32k.
Limits with '+' in front of the number say that this is the max value
tested, without implying whether higher values are OK or not.
If you have any remarks, especially about the '=no' results (i.e. you
think PostgreSQL can do that, therefore the crashme test must be wrong
somehow), tell me. Otherwise I'll forward the results to the MySQL
people next week.
The crash-me test script, BTW, is included in MySQL's sql-bench
subdirectory.
--
Matthias Urlichs | noris network GmbH | smurf@noris.de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
The real character of a man is found out by his amusements.
-- Joshua Reynolds