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

Hi,

[ Sorry if this reply is much too long. I know that...]

Bruce Momjian:
> I know I am going to regret believing that I will actually make any
> difference, but I am going to shoot myself anyway.
>
I sincerely hope/believe you're wrong.

> > What does the official standard say (assuming any exists) -- is the "to"
> > optional or not?
>
> I don't see any RENAME in the SQL92 spec. Now, how hard is it to do a
> 'man alter_table' and see what it says at the top of the screen?
>
It's not a question of your manpage vs. their manpage. I can read your
manpage just fine. It's a question of whether there is somethign that
can be regarded as a standard on it or not. "Official" is a poor wording
in this case -- sorry.

If yes, then the test will be changed to do it the standard way.
If no, then I might have to test for both syntaxes, which is a PITA.

While I'm at it, I note that the last sentence of that manpage says

The clauses to rename columns and tables are Postgres extensions
from SQL92.

Correct me when I'm wrong, but is that really _your_ extension, or
did some other database vendor (who?) come up with it?

> > Anyway, $max_connections has the value to 1000.
>
> You have to recompile the backend to increase it. Not on the client
> end. See FAQ.

I was compiling and running the backend with default options(*). That
means that the tests will show the default limits. It does this for all
the other databases in the crash-me test result suite. (Oracle:40,
mysql:100, solid:248, empress:10, interbase:10)

Anyway, the max value for PostgreSQL, without recompiling the backend,
is 1024 according to the FAQ; but there's no way an automated test can
find out _that_.

I'll add a comment ("installation default") to that test column.

(*) except for fsync, of course, in the interest of fairness.

> man create_table. That is all it takes. There is not standard for
> this. It is from Oracle. Is their AS optional? Does it really matter?
>
No.

What matters is that your opinion is that they are responsible for making
the test 100% accurate. Their reply to that is that many database
vendors actually provided fixes for this test instead of bitching
about how inaccurate it is, thus they feel the obligation is on your
side.

Now I am of neither side. I am, IMHO, thus in a position to ask you
about your opinion of these inaccuracies, I am going to change
the crashme test to be a whole lot more accurate WRT PostgreSQL,
I will feed these changes back to the MySQL people, and they'll
incorporate these changes into their next release. (Their head honcho
(Monty) has said so on their mailing list. I _am_ going to take him up
on it, and I can be quite obnoxious if somebody reneges on a promise.
*EVIL*GRIN* )

If your opinion is that you have a right to be annoyed about all of this
because you went through the whole thing last year, and the year before
that, and ..., ... well, I can understand your point of view.

But I honestly think that the problem is not one of either malice or
stupidity. "Different sets of priorities" and "different project
structure" are equally-valid assumptions. At least for me. Until I'm
proven wrong (IF I am).

> So you test EXCEPT by having a different number of columns. I can see
> it now, "Hey we don't have EXCEPT. PostgreSQL does it, but they can't
> handle a different number of columns. Let's do only that test so we
> look equal."
>
They might as well have written that test while checking their crash-me
script against SOLID and noting a few features MySQL doesn't have yet.
Or they may have gotten it from them in the first place.

I might add that their test lists 52 features of PostgreSQL which
MySQL doesn't have (13 functions). It also lists 122 features of MySQL
which PostgreSQL doesn't have; 78 of those are extra functions (40 of
these, just for M$-ODBC compatibility).

So it seems that overall, that crash-me test result is reasonably
balanced (39 vs. 44 non-function differences -- let's face it, adding
another function for compatibility with SQL variant FOO is one of the
easier exercises here, whatever the current value of FOO is).

The result is going to be even more balanced when I'm through with it,
but I cannot do that on my own, as I do not have enough experience with
either PostgreSQL or the various SQL standards. Thus, I'm asking.

Is that really a problem?

> If you view this from outside the MySQL crowd, can you see how we would
> feel this way? This is just a small example of the volumes of reasons
> we have in believing this.
>
I would like not to view this from any outside, inside, or whatever
viewpoint. My goal is to get at least some part of the petty arguments
out of the way because, in MY book at least, the _real_ "battle", such
as there is, isn't PostgreSQL against MySQL! It's more-or-less-
-open-source databases on one side and closed-source products, some of
which are the equivalent of MS Word in the database world (you know who
I'm talkign about ;-) on the other side.

> It never has been fair, and I suspect never will be, because this is
> hashed around every year with little change or acknowledgement.
>
It is about as fair as a certain comparison chart on your site has been.
It's gone now, thus as far as I'm concerned it's water under the bridge.
Besides, I'm not interested. Some of the members of this list seem
to be pretty much burned out on the whole issue -- I can live with that;
but I'm trying to do something about the problem. Don't shoot the
messenger. ;-)

--
Matthias Urlichs | noris network GmbH | smurf(at)noris(dot)de | ICQ: 20193661
The quote was selected randomly. Really. | http://smurf.noris.de/
--
Lady Luck brings added income today.
Lady friend takes it away tonight.