Re: Performance (was: The New Slashdot Setup (includes MySql server))

Matthias Urlichs wrote:
> 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.

How about:

1. alter_rename_table = no

The syntax in PostgreSQL is ALTER TABLE x RENAME TO y;

2. atomic_updates = no

Huh? Besides being paranoid about fsync()'ing transactions how is
a transaction based MVCC not atomic with respect to updates?

3. automatic_rowid = no

The description simply says Automatic rowid. Does this apply to
query result sets or to the underlying relation? If the latter,
PostgreSQL has, of course, an OID for every tuple in the
database.

4. binary_items = no

Read up on large objects...

5. connections = 32

This, should, of course be +32, since PostgreSQL can easily
handle hundreds of simultaneous connections.

6. create_table_select = no

Again. PostgreSQL supports CREATE TABLE AS SELECT (i.e. Oracle),
and SELECT INTO syntax.

7. except = no

PostgreSQL has had both INTERSECT and EXCEPT since 6.5.0 (albeit
they're slow).

I'm starting to get very tired of this. I don't see why
PostgreSQL users are obligated to get MySQL tests correct. And
I'm only 15% through the list...

Bottom line...either the test writers are ignorant or deceptive.
Either way I won't trust my data with them...

Mike Mascari