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

Hi,

Mike Mascari:
>
> 1. alter_rename_table = no
>
> The syntax in PostgreSQL is ALTER TABLE x RENAME TO y;
>
They say "alter table crash_q rename crash_q1".

What does the official standard say (assuming any exists) -- is the "to"
optional or not?

> 2. atomic_updates = no
>
> Huh? Besides being paranoid about fsync()'ing transactions how is
> a transaction based MVCC not atomic with respect to updates?
>
That's a misnomer. They actually mean this:

create table crash_q (a integer not null);
create unique index crf on crash_q(a);

insert into crash_q values (2);
insert into crash_q values (3);
insert into crash_q values (1);
update crash_q set a=a+1;

> 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.
>
I'll have them fix that. MySQL calls them "_rowid" and apparently tests
only for these.

> 4. binary_items = no
>
> Read up on large objects...
>
... with an ... erm ... let's call it "nonstandard" ... interface.

> 5. connections = 32
>
> This, should, of course be +32, since PostgreSQL can easily
> handle hundreds of simultaneous connections.
>
The testing code (Perl) looks like this, and it bombs after the 32nd
connection.

for ($i=1; $i < $max_connections ; $i++)
{
if (!($dbh=DBI->connect($server->{'data_source'},$opt_user,$opt_password,
{ PrintError => 0})))
{
print "Last connect error: $DBI::errstr\n" if ($opt_debug);
last;
}
$dbh->{LongReadLen}= $longreadlen; # Set retrieval buffer
print "." if ($opt_debug);
push(@connect,$dbh);
}
print "$i\n";

I do not know where that limit comes from.
It might be the DBI interface to PostgreSQL, or a runtime limit.

Anyway, $max_connections has the value to 1000.

> 6. create_table_select = no
>
> Again. PostgreSQL supports CREATE TABLE AS SELECT (i.e. Oracle),
> and SELECT INTO syntax.

Test code:
create table crash_q SELECT * from crash_me;

Again, is the "AS" optional or not?

> 7. except = no
>
> PostgreSQL has had both INTERSECT and EXCEPT since 6.5.0 (albeit
> they're slow).
>
Looking at the test, we see it doing this:

create table crash_me (a integer not null,b char(10) not null);
insert into crash_me (a,b) values (1,'a');
create table crash_me2 (a integer not null,b char(10) not null, c integer);
insert into crash_me2 (a,b,c) values (1,'b',1);
select * from crash_me except select * from crash_me2;

For what it's worth, there is at least one database which doesn't
have this restriction (i.e., that the number of columns must be
identical) (namely SOLID).

So this test needs to be split into two. I'll do that.

> 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...
>
_Somebody_ has to get these things right. I'm not suggesting that it's
any obligation of yours specifically, but somebody's gotta do it, and
(IMHO) it can only be done by somebody who already knows _something_
about the databse to be tested.

> Bottom line...either the test writers are ignorant or deceptive.

Or the tests are just badly written. Or they're too old and suffer from
severe bit rot.

For what its worth, I do NOT think the people who wrote these tests
are either ignorant or deceptive. Most, if not all, of these tests
are OK when checked against at least one SQLish database.

--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
Freedom of opinion can only exist when
the government thinks itself secure.
-- Bertrand Russell (1872-1967)