MySQL Bugs: #56262: REPAIR STATUS

Bug #56262	REPAIR STATUS
Submitted:	25 Aug 2010 16:42	Modified:	21 Mar 2011 4:19
Reporter:	Roberto Spadim (Basic Quality Contributor)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: General	Severity:	S4 (Feature request)
Version:	5.5	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	qc

Description:
Hello, when i have problems with UPS every body ask "how many time to repair table XXXX?", i answer "i don't know...".

could we put more information on processlist?

tree fields...
start position
current position
end position

start - the first byte of table
end position - the last byte of table
current - the current byte read in the table repair

i don't know if it could be used for anothers informations like SELECT, UPDATE, DELETE, etc etc, cause it could spend more time on query execution, but maybe it could be very interesting

how can i know when the repair end?

check current position now (00:00:00), check current position after some time (00:00:10) dif(position)/dif(time) = positions / second, (end-start)/position/second = seconds to end =D

got ?

How to repeat:
repair a very big table (10gbytes) after a crash
it's will take about 4 hours...

but...
how many time it will take?
about is not a very acurate value....

a more precise value can be obtained, or a aproximation... =] hehe
like bytes read / second, total table size
total table size / bytes / second = how many seconds to repair table

maybe a flag in query...

REPAIR TABLE WITH_PROGRESS table_name

or 

REPAIR TABLE /*WITH_PROGRESS*/ table_name

since some tables are very small repair table don't take a lot of time... just some minutes...

Thank you for the useful feature request.

is this a duplicate of bug #26182 ?

yes, could it be done for repair too? i don't know anythink about repair and expected rows... since query result is one row for mysql client... (maybe many for mysql server...)
any idea? i think it's ok 

query progress, or operation progress, since it can be sending data to client, preparing query, executing...

ideas?

i will close it's a duplicate of bug 26182