Steven Roussey writes:
>
> Some clarification. On this table there are a lot of indexes, but there is
> one unique/primary key, and it is that one that the replace should be
> checking for. The other indexes have the same fields in different places
> though. Table key def is something like t
> > There can be another source of problems with REPLACE. As it has to
> > DELETE a row first, it might take a lot of time on huge table if MySQL
> > is not able for some reason to utilize index in order to locate rows.
>
> Now this seems like it might be related. On a variable sized row
> table,
> Safest thing for you is to use our latest 3.23 binaries which are
> statically linked with stable glibc and with some additional patches.
For this reason and greater simplicity :) I have been using your binaries
for a long time now. Part of the reason we never tested BDB tables...
> There can
y, February 23, 2001 3:23 PM
Subject: Re: INSERT/REPLACE lock up in 3.23.33
> Steven Roussey writes:
> > > My troubles continue with INSERTs (i posted a message about
INSERT
> > > DELAYED crushing a server before). Now, I have this:
> >
> > We are
Steven Roussey writes:
> > My troubles continue with INSERTs (i posted a message about INSERT
> > DELAYED crushing a server before). Now, I have this:
>
> We are running Linux and MySQL 3.23.30 and have similar problems. In
> particular we have a lot of INSERT DELAYEDs into a fixed table, an
> My troubles continue with INSERTs (i posted a message about INSERT
> DELAYED crushing a server before). Now, I have this:
We are running Linux and MySQL 3.23.30 and have similar problems. In
particular we have a lot of INSERT DELAYEDs into a fixed table, and REPLACE
DELAYED into a variable size
Hello!
My troubles continue with INSERTs (i posted a message about INSERT
DELAYED
crushing a server before). Now, I have this:
osiris:/root-> mysqladmin processlist
++--+---+---+-+--++---
