Hi!
On Wed, Sep 12, 2001 at 04:53:53PM +0300, monty@stripped wrote:
>
> >>>>> "Benjamin" == Benjamin Pflugmann <philemon@stripped>
> writes:
>
> Benjamin> Hello again.
> Benjamin> I finally made a patch of my current working version. After I upgraded
> Benjamin> from 3.23.40 to 3.23.42 I had problems compiling, though. I had to
> Benjamin> change sql/gen_lex_hash.cc, but since I am not really knowing what I
> Benjamin> am doing here, there is probably a better fix. I did the following
> Benjamin> change (applied with patch -p1 -d your-mysql-src < patch-file):
[...]
>
> Yes, you have to modify gen_lex_hash.cc to get the new keywords in.
> I will look into into getting better numbers for the arrays on my machine.
Ah. Good.
> I will examine and apply this to 4.0 during the next few days.
You know, this is not what I intended as final version? The change to
.frm files is still missing (and some cleanup as I understand the
source a bitter now).
> I will then email you some comments about this.
Additionally, I yesterday made a real-world test and found that
REPLACE doesn't work as expected (if replacing an existing row):
- If the old row is in a different table that the inserts are made,
one has to rows with same id afterwards.
- If the tables of the old row and the insert are the same, the new
one doesn't replace the old one but on gets an "duplicate key"
error.
Sigh.
Another thing is, that on identical tables (the unique columns are
also unique for the MERGE table), EXPLAIN gives different results in
some cases, using filesort to satisfy an ORDER BY although it uses an
index to read the column in.
Well, some more things for me to investigate ;-)
Now, how do we proceed most reasonably? Would it be better that I wait
(with changes) until you can say something about the original problem
with ALTER TABLE. And if not, are patches better against my former
patch or against the original?
Bye,
Benjamin.
