myisamchk vs OPTIMIZE TABLE

2004-02-08 Thread Mark Hazen
Hi all!

Running 4.0.17.

I hope this isn't a stupid question, but it appears that OPTIMIZE TABLE is
NOT equivalent to:
myisamchk --quick --check-only-changed --sort-index --analyze

Maybe I'm missing something, but OPTIMIZE TABLE rebuilds both the data file
and the index file (I see a TMD and TMM file being built).  myisamchk only
appears to rebuild the TMM file.  Why is this?  How do you get the
equivalent OPTIMIZE TABLE in myisamchk?

Thanks
Mark


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: myisamchk vs OPTIMIZE TABLE

2004-02-08 Thread Mark Hazen
In reference to my earlier message, I think I've figured out that the
equivalent command for OPTIMIZE TABLE is:
myisamchk -r --sort-index --analyze

That isn't documented anywhere... and in fact, the French language version
says something conflicting (I don't speak French but a Google search brought
me there).

Here's my problem: I've got a bunch of tables with hundreds of millions of
rows in them.  Every night, I delete about couple million rows and then run
millions of searches on these tables.

What should I worry about more?  A sorted index or a data file with no
deleted rows in it?

I don't mind running either OPTIMIZE TABLE (which apparently rebuilds
everything and sorts it) or just the myisamchk to sort the index.  Does
anyone know which one might get me more mileage?

Thanks!
Mark

> -----Original Message-
> From: Mark Hazen [mailto:[EMAIL PROTECTED]
> Sent: Sunday, February 08, 2004 11:46 AM
> To: [EMAIL PROTECTED]
> Subject: myisamchk vs OPTIMIZE TABLE
>
>
> Hi all!
>
> Running 4.0.17.
>
> I hope this isn't a stupid question, but it appears that OPTIMIZE TABLE is
> NOT equivalent to:
> myisamchk --quick --check-only-changed --sort-index --analyze
>
> Maybe I'm missing something, but OPTIMIZE TABLE rebuilds both the
> data file
> and the index file (I see a TMD and TMM file being built).  myisamchk only
> appears to rebuild the TMM file.  Why is this?  How do you get the
> equivalent OPTIMIZE TABLE in myisamchk?
>
> Thanks
> Mark
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/[EMAIL PROTECTED]
>


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: myisamchk vs OPTIMIZE TABLE

2004-02-08 Thread Mark Hazen
> What's the nature of your query?
>
> If it's using an integer index and that's what your searching on, then
> having
> it physically sorted is a Good Thing. If you're table-scanning your
> main table, you're toast anyway. Finding ways of making that faster is
> the
> way to go, maybe partitioning your data into "small, fixed width,
> fields I
> care about" and "other stuff" is the way to go?
>

My tables are just 2 INT columns.  I have unique indexes on them going both
ways.

Thanks
Mark


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: myisamchk vs OPTIMIZE TABLE

2004-02-08 Thread Mark Hazen

> You know, this might sound strange, but does the performance drop off at
> all if you lose the indices? A table scan of rows 8 bytes wide is going
> to be pretty damn quick. Plus there's a lot less maintenance to do
> without
> indices and no risk of them getting corrupted.

A full table scan is never going to be faster than using indexes when you're
running several hundred million rows.

Does anyone else have any thoughts?

Does anyone know the charge you take in having deleted rows?  Or an unsorted
index?  Which is worse?

Thanks
Mark


-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: Attn: MySQL AB: we need 3.23.5x NOW !

2002-06-07 Thread Mark Hazen


> Can someone *please* pick up the dropped ball on the
> release schedule and run with it ? It's not such
> a big deal for ISAM table users but it's a very big
> deal for InnoDB tables...
>

MySQL AB: The least you could do is say: OK, we have this X problem and
still working out Y... but we anticipate being finished next week.  Then
we'll spend about a week testing the build, and it will be live.

Instead we get Monty talking about posting 3.23.50 in a week about 2 months
ago.  Then nothing... dead caller at the other end!

Please help!!! Anyone?!
Mark


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php