overy to 3 to
>
> bring the database up without the rollback, then DROP the table that is
>
> causing the runaway rollback):
>
> http://dev.mysql.com/doc/mysql/en/forcing-recovery.html
>
>
>
>
>
>
>
> Joseph Cochran <[EMAIL PROTECTED]> w
ur own...
>
> That's a LOT of data...
>
> Also.. if the kill works you could still delete in the future but put a
> LIMIT on the delete clause. This way you can determine how long your
> delete's will take.
>
> Kevin
>
> On 9/6/05, Joseph Coch
Here's the situation. I have a table of about 900 million rows, consisting
of a bigint and an int in each row. There's an index on the bigint. The
table is referenced in a SELECT in other DB operations roughly 15 or 20
times per day.
We're under tight deadlines and some operations on the table
Some countries have multiple timezones, so it is not sufficient to
know the country code in order to get the timezone. If they have
previously posted the timezone, however, then it should be possible to
store that information in a cookie on the client machine that your web
layer can retrieve. If yo
ne how efficient your indexes are. Using a lot of
>
> keys could slow down the INSERT operations but fasten the SELECTs.
>
> InnoDB monitors might be helpful in your case as well. See:
>
> http://dev.mysql.com/doc/mysql/en/explain.html
>
> http://dev.mysql.co
So here's my situation: we have a database that has a table of about 5
million rows. To put a new row into the table, I do an INSERT ...
SELECT, pulling data from one row in the table to seed the data for
the new row. When there are no active connections to the DB other than
the one making the INSE
We've been using mysql version 4.7 on a FreeBSD 4.10 machine for the
past few months, and while we've been putting a lot of load onto the
DB, it's been stable. This past weekend, our sysadmin updated FreeBSD
from 4.10 to 4.11, at which point mysql began having serious problems.
The DB itself is fin
On Mon, 23 Aug 2004 15:25:21 +0200, Martijn Tonies <[EMAIL PROTECTED]> wrote:
> > > I have a questions about "varchar columns" change to "CHAR columns"
> > > automatically.
> > See http://dev.mysql.com/doc/mysql/en/Silent_column_changes.html
> In addition to that - it doesn't really matter as th
